<@U6FBJKWBV> <@U2CSHP1HA> This limitation of `..` ...

# getting-started

[voddan]

@horse_badorties @johnaqel This limitation of .. is made so to emulate the traditional for loop. In a code for(int i = A; i < B; i++){} nothing happens if A is greater than B. This is how programmers are accustomed to think about iterations. If the .. loop worked both ways, the number of bugs would be colossal.

[horse_badorties]

I have to disagree, @voddan.

3..1 returning an IntRange with step = 1 rather than -1 is un-intuitive and I'm quite sure I'm not alone.
How is 2 in 3..1 == false intuitive? Or "d" in "z".."a" == false?
When would it ever make sense to use 3..1 anyway?

Your argument is a bit like saying when should fall-through because that's how programmers are accustomed to think about switch..case 🙂

I believe kotlin rookies (like me) falling for this will outnumber those who intuitively expect the current behaviour and I second @kevinmost's suggestion to at least add a lint warning.

[voddan]

A lint warning is always welcome, but it will mostly work when the range diapason is constant

[voddan]

What I wrote is not my opinion, but the actual reasoning used when designing this feature. It was decided that parity with Java's for(i = A; i < B; i++) and A <= x && x <= B constructs was more important than anything else.

[voddan]

I personally totally agree with that design decision. IMO developers start to appreciate the explicitness of it when they work with non-constant expressions like start in calculateLeft()..calculateRight()

[kevinmost]

I agree with the decision as well. As Daniil state, for non-constant expressions, the behavior can be unexpected no matter which you go with. At least this way though, there's no implicit behavior, which has always been a design goal of Kotlin.

But yes, there should be a lint warning IMO when you have two constants (or if the variables can be statically analyzed to be in a certain range) and the left is greater than the right