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()

.

janvladimirmostert: I would suspect to avoid confusion when the parameters (1 and 4) are not constants.

@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

well, that's not what the operator does though.

could probably override it to first check if a > b, then do a rangeTo otherwise return a rangeDownTo

@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.

Well, my expectations are different then 😄

@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

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.

I could probably just do this:

operator fun Any.rangeTo(b: Any) = if (this > b) getAscendingRange(a,b) else getDescendingRange(a,b)

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.

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]

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

luckily Kotlin is flexible enough that I can override it for our purposes

If the “flexible” behaviour, almost any piece of practical code would always have to add an extra check.

indeed, but in this specific project, we don’t mind things going into the negative, so no checks needed

For redability, though, I’d suggest to introduce your own infix function for that (instead of redefining

rangeTo

operator)

Since Kotlin is not Scala, I’m guessing at no stage in the future will Kotlin allow defining custom operators?

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.

i’ve seen that feature abused so badly that code becomes unreadable 😄