https://kotlinlang.org logo
Title
j

janvladimirmostert

06/14/2017, 11:39 AM
I’m curious, what was the design decision that made
1..4
return you a list, but
4..1
doesn’t return anything. One would expect
4..1
equals
(1..4).reversed()
.
👍 3
d

diesieben07

06/14/2017, 11:41 AM
janvladimirmostert: I would suspect to avoid confusion when the parameters (1 and 4) are not constants.
👍 1
If you use .. you expect to get an ascending sequence
j

janvladimirmostert

06/14/2017, 11:43 AM
@diesieben07 actually, I’m not expecting an ascending sequence, the expectation is to get a sequence containing the range whether it’s ascending or descending
d

diesieben07

06/14/2017, 11:43 AM
well, that's not what the operator does though.
j

janvladimirmostert

06/14/2017, 11:45 AM
could probably override it to first check if a > b, then do a rangeTo otherwise return a rangeDownTo
h

holgerbrandl

06/14/2017, 11:48 AM
@diesieben07 In R
base::seq(5,1)
gives a descending sequence, so I’d think not everyone is expecting an ascending sequence. I would not either. I agree with @janvladimirmostert about the expected behavior.
👍 1
d

diesieben07

06/14/2017, 11:49 AM
Well, my expectations are different then 😄
e

elizarov

06/14/2017, 11:54 AM
@diesieben07 Is right. Kotlin is not Python. You have to be explicit on whether you want ascending (
..
or
rangeTo
) or descending (
downTo
) sequence. More here: https://kotlinlang.org/docs/reference/ranges.html
h

holgerbrandl

06/14/2017, 11:56 AM
The javadocs just state that it
creates a range from this value to the specified other value
, so if
this
is greater than
other
the resulting sequence should start with
this
to fulfill its contract.
j

janvladimirmostert

06/14/2017, 11:57 AM
I could probably just do this:
operator fun Any.rangeTo(b: Any) = if (this > b) getAscendingRange(a,b) else getDescendingRange(a,b)
😄
e

elizarov

06/14/2017, 11:59 AM
You can. But I would not recommend. It is very hard to debug the practical algorithms with this Python-style definition, as incorrect input parameters would lead to subtle bugs.
For example, when you write
1..i
in your code you usually know it has to be ascending and you don’t want it to do anything when
i
is zero or negative
It is just pragmatism in action
j

janvladimirmostert

06/14/2017, 12:01 PM
coming from a Python background 7 years ago, I would argue, if you put
1..-2
in there, you would expect a list
[1, 0, -1, -2]
otherwise it should throw an exception if it’s expecting the second parameter to be bigger than the first.
Currently it “fails” silently.
e

elizarov

06/14/2017, 12:03 PM
That is what you expect most of the time in practise. If you want to something to be done
n
times, then you expect
(1..n).forEach { ... }
to be not doing anything when
n == 0
☝️ 2
That is just the most common expected behavior. It is also a safe bet for
n < 0
.
This lets you avoid extra check in most practical code I’ve seen, but it always Ok to add extra check when you need it.
j

janvladimirmostert

06/14/2017, 12:05 PM
luckily Kotlin is flexible enough that I can override it for our purposes
e

elizarov

06/14/2017, 12:06 PM
If the “flexible” behaviour, almost any piece of practical code would always have to add an extra check.
Of course, you can always override it (that is Kotlin)
👍 1
j

janvladimirmostert

06/14/2017, 12:06 PM
indeed, but in this specific project, we don’t mind things going into the negative, so no checks needed
e

elizarov

06/14/2017, 12:08 PM
For redability, though, I’d suggest to introduce your own infix function for that (instead of redefining
rangeTo
operator)
But, that is all domain-specific. If that is all you need in your domain, then redefining
rangeTo
is also Ok.
j

janvladimirmostert

06/14/2017, 12:11 PM
Since Kotlin is not Scala, I’m guessing at no stage in the future will Kotlin allow defining custom operators?
infix
pyRangeTo
is probably good enough, makes code more readable
👍 1
e

elizarov

06/14/2017, 12:13 PM
There are no plans to support custom operators in the near future. The example of Scala is educating enough to discourage all future language designers from doing that.
❤️ 2
👍 3
j

janvladimirmostert

06/14/2017, 12:14 PM
i’ve seen that feature abused so badly that code becomes unreadable 😄
Some day we might see a “Project Lombok”-like project for Kotlin that allows custom operators written by Scala devs who now have to write Kotlin :troll: