Switching to exclusive upper bound for slicing

[Night-walker]

In Dao, slicing with [n : m] implies [n; m] bounds. It may make sense to switch to [n; m) instead. Same applies to for (i = n : m) loops.

Reasons to switch:

• this is undoubtedly the most practical use case (I can't even remember a situation when it wasn't the case)
• this is how slicing works in most other languages supporting it

It is less intuitive if you've never seen slicing before, but more natural if you have.

[dumblob]

IIRC we already discussed this few years ago, but I can't find a proper reference. Either way, I was proposing the same, so I have no objections against your proposal.

[daokoder]

this is how slicing works in most other languages supporting it

Not necessarily. See: https://en.wikipedia.org/wiki/Array_slicing.

It is less intuitive if you've never seen slicing before, but more natural if you have.

Not very convincing. Also, it would make it awkward to use negative indices (to index from the end). For example, how would you express the current a[-2 : -1] after the change? a[-2 : 0] would look very confusing.

[Night-walker]

this is how slicing works in most other languages supporting it Not necessarily. See: https://en.wikipedia.org/wiki/Array_slicing.

OK, I was biased after some time with Python and Rust. That article, however, is full of endemic languages, but looking at Ruby and Ceylon makes it clear that there is no widely accepted approach.

Not very convincing. Also, it would make it awkward to use negative indices (to index from the end). For example, how would you express the current a[-2 : -1] after the change? a[-2 : 0] would look very confusing.

Simply a[-2 :]. I agree that it's kinda confusing at first look, but currently slicing in Dao virtually always takes form of x[n : m - 1] -- getting rid of that - 1 might be worth it.

Or perhaps we could simply introduce additional convenience syntax to elide the boilerplate code. It's a minor and subjective issue, however, so I won't insist on any change.

[daokoder]

but currently slicing in Dao virtually always takes form of x[n : m - 1]

It depends on how you understand slicing, for me: it is a pair of starting index and ending index, so there is no issue of -1.

[Night-walker]

It depends on how you understand slicing, for me: it is a pair of starting index and ending index, so there is no issue of -1.

The actual code doesn't depend on understanding: its expr1[expr2 : expr3 - 1] in roughly 95% of cases.

[daokoder]

The actual code doesn't depend on understanding: its expr1[expr2 : expr3 - 1] in roughly 95% of cases.

Here you are assuming expr3 will most often produce the index following the slicing, but I don't see why this is the case. Unless expr3 is something very common, I don't see why -1 cannot be considered as a part of expr3. Some examples might be helpful.

[dumblob]

I'm surprised - I ran grep -E '[[][^]:]+:[^]]+[]]' *dao in different folders with my Dao sources and got 6 results in total (out of several thousands of lines in Dao). That means, I'm almost not using slicing :(

[Night-walker]

Usually the end index of slice is the index preceding certain delimiter or barrier value:

pos = str.find('pattern')
substr = str[: pos - 1]

end = lst.find {X <= 0}
range = lst[start : end - 1]

for (i = 0 : %lst - 1) ...

For instance, I can hardly recall a case when explicit end slice boundary did not require - 1 when working with strings (except for special i : i). This is exactly the reason why languages adopt this semantics in the first place.

However, this may appear somewhat confusing with things like string::scan()[] yielding start and end indices -- languages with no-copy slicing has no need for such approach, but it's unavoidable in Dao in some cases. And that i : i slicing (which I used occasionally for convenience) would require + 1 in case of the change :) Taking this into account, attractiveness of index shifting quickly diminishes...

But having an extra, auxiliary slicing syntax might still be worthy of discussing.