https://kotlinlang.org logo
#random
Title
# random
g

Gleb Minaev

03/02/2023, 7:15 AM
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.)
👍 7
I have a case where IMO
firstToIncrease <..< k
is more readable than
(firstToIncrease + 1) ..< k
.
2
e

ephemient

03/02/2023, 8:06 AM
honestly I would have preferred Raku's operators:
..
inclusive-inclusive
..^
inclusive-exclusive
^..
exclusive-inclusive
^..^
exclusive-exclusive
😆 3
😂 2
e

elizarov

03/02/2023, 4:19 PM
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.
👍 1
g

Gleb Minaev

03/02/2023, 5:03 PM
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!
e

elizarov

03/03/2023, 9:05 AM
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.
g

Gleb Minaev

03/03/2023, 9:10 AM
It is sad but I cannot disagree with the point. Thanks!
e

ephemient

03/03/2023, 11:42 AM
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.
e

elizarov

03/03/2023, 1:36 PM
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.
👍 1
r

ribesg

03/03/2023, 3:10 PM
>..<
😆 1
😂 6
5 Views