Ranges: Inclusive and exclusive operators

[Gundolf68]

for i in 1..5 {
   println(i)
}
// incl (..): will print 1, 2, 3, 4, 5

for i in 1...5 {
   println(i)
}
// excl (...): will print 1, 2, 3, 4

[SleepyRoy]

I agree with having the two operators, but propose the different syntax below.

for i in 1..5 {
     println(i)   // 1,2,3,4,5
}

for i in 1<..5 {
    println(i)  // 2,3,4,5
}

for i in 1..<5 {
    println(i)  // 1,2,3,4
}

for i in 1<..<5 {
    println(i)  // 2,3,4
}

The advantage of this syntax is that you don't need to "count" how many dots are there (which I think is error-prone).

[SleepyRoy]

And similarly maybe we could consider this...

arr := [0,1,2,3,4,5]
println(arr[1..4])  // [1,2,3,4]
println(arr[1<..4])  // [2,3,4]
println(arr[1..<4])  // [1,2,3]
println(arr[1<..<4])  // [2,3]

[Delta456]

We already have this

for i in 1..5 {
   println(i)
}

Output

1
2
3
4

[SleepyRoy]

@Delta456 Yes. Since V has a philosophy of "unique way", maybe keeping the current syntax (there's only one range operation - a..b means [a,b) ) is not bad.

[lammel]

I probably missed the discussion around the current range operator, but I find a mix of inclusive and exclusive rather unintuitive.

I would have expected that a loop over 1 to 3 does include 3:

for i in 1..3 {
   println(i)
}

Output:

1
2
3

I would prefer to have the default as a intuitive as possible. And advanced syntax is usually not needed if math operators will do the trick.

In case the code below is working, I guess no additional sytnax is required.

for i in 1..len(mylist)-1 {
   println(i)
}

[ghost]

A '1..5' range not including '5' although completely counterintuitive at first sight, makes sense about zero base arrays:

for i in 0 .. my_array.len { my_array[i] = some_value } // not bad!

MAYBE a new language derived from V (just the one base arrays part) could work fine.

[ghost]

for x in [1,2,3,4,5] { print(x) } // 12345 // inclusive
           
for x in 1..5        { print(x) } // 1234  // exclusive

I have no proposal about this.
A just want to point how counterintuitive this range design is.

[Gundolf68]

I have no proposal about this. A just want to point how counterintuitive this range design is

Yes: Take a look at "wren" http://wren.io/values.html#ranges - i think they do it right.

[ghost]

@Gundolf68

Don't get me wrong.
If I had the power to decide about V:

• only base one arrays (indexing) would exist
• for i in 1..5 // would mean 12345
• the operator '...' would not exist

As the decision is not for me, I try to understand what are the reasons of Alex Medvednikov.

I think he wants a language where C programmers feel at home.
Probably the language design is in part driven by marketing (culture).

That is why I said I had no proposal, because I fear that some features that I love have no match with strategy/culture/market of V.

[txgruppi]

We have ... used with match and .. used with for.

I don't find .. confusing, it is a open ended range.

Anyway, it would be nice to have ... with for.

---

Please don't lua the language. Base 1 arrays are annoying to work with. I have experience with base 1 arrays and image/matrix processing, what a nightmare.

[JalonSolov]

These topics have been discussed many times in the past, and I suppose will keep coming up from time to time. This is why V needs ADRs.

Arrays in V will always start at 0. 98+% of programming languages start arrays at 0. V is similar to Go, which starts arrays at 0, and V outputs C by default, which starts arrays at 0. V can also output JavaScript (where arrays start at 0), Python arrays start at 0, etc., etc.

for uses an exclusive range for many reasons. Try reading https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html for why exclusive ranges are better. E. W. Dijkstra has a pretty good reputation...

for will not use both .. and .... This was argued many times on discord, and always comes back to the possibilities of hard-to-detect problems with 2 operators that are very similar but can have catastrophic results (array index out of range, causing a panic, perhaps?). It is simply too easy to type only 2 .. when you meant 3, or a "bouncy" keyboard giving you 3 when you only meant 2. Errors that won't show up until runtime.

match, on the other hand, always uses inclusive ranges. Same reasons for not using both. It's bearable because trying to use .. with match will give a syntax error, same as ... will with for.

[viocha]

We already have this

for i in 1..5 {
   println(i)
}

Output

1
2
3
4

So inclusive end is enough:

for i in 1..=5 {
   println(i) // 1, 2, 3, 4, 5
}

[gchumillas]

I like Rust's ..= notation, however we already have ... in the match construction:

typ := match c {
    `0`...`9` { 'digit' }
    `A`...`Z` { 'uppercase' }
    `a`...`z` { 'lowercase' }
    else { 'other' }
}

[maiolika]

For now a..b == [a, b) and it's a bit confusing because left-side inclusive and right-side exclusive but both looks the same.
My suggestion is

a..b == [a, b] // right-side inclusive
a..<b == [a, b) // right-side exclusive

There's no need for this but it would be nice to have this as a syntactic sugar.