I am just interested in opinion of the community. ...

# random

[Gleb Minaev]

I am just interested in opinion of the community. Am I only one who wants by analogy with ..< operator to have <.. and <..< operators? (Vote with 👍 if you want the operators too and 👎 otherwise.)

[Gleb Minaev]

I have a case where IMO firstToIncrease <..< k is more readable than (firstToIncrease + 1) ..< k.

[ephemient]

honestly I would have preferred Raku's operators:
.. inclusive-inclusive
..^ inclusive-exclusive
^.. exclusive-inclusive
^..^ exclusive-exclusive

[elizarov]

They are needed so much less often that it is really hard to justify adding even more operator complexity for them. Even convincing everyone that ..< makes sense was a fair amount of work.

[Gleb Minaev]

Well, I not so rarely meet cases with complex logic that is prone to off-by-one mistakes. So it would be great if I could translate sentences like "iterating from start exclusively to end exclusively" to code as-is, i.e. to for (smthng in start <..< end). But I have to translate them to interval definition like (start+1) .. (end-1), that is not so easy to read. And infix functions like until makes it even worse because I have to understand the meaning of the infix operator. Whereas the operator .., etc. is much easier to read and < suffix or postfix does not change the operator's image a lot, so its easier for me to read them instead of infix operators or ±1 corrections.

And I think that meaning of <..< is not so hard to understand if you've seen .. before. Which is not true for some really strange non-verbal operators in other programming languages.

For example, I just wrote a function that creates a sequence of k-permutations of elements from some given list sorted in lexicographic order. And I feel that I want to curse the inability to write <..<.

But that is my subjective opinion. So I just wanted to listen to other opinions and to know if it's really my own problem. So thanks everyone for the answers!

[elizarov]

It is not just a complexity with having many baroque operators, it is also complexity in the standard library to support all of them. So far, we cannot convince ourselves that this added complexity is worth the benefit.

[Gleb Minaev]

It is sad but I cannot disagree with the point. Thanks!

[ephemient]

if we could switch to completely different types, I might propose something like this. I can't really say it would be worth the trouble to migrate now, though.

Untitled.cpp

[elizarov]

Looks similar to C#, if I am not mistaken. Unfortunately, making a “isMin/MaxExclusive” runtime properties not only adds a great deal of complexity (every code must check them), but also sacrifices runtime performance.

[ribesg]

>..<