[start..end] and [start:len] slice syntax

[1player]

If I didn't catch this note in the FAQ, I wouldn't have noticed a possible bug in my code where I expected [start:end] as it is in many languages (Python & co.) rather than [start:len].

Either one is fine, but having both syntaxes, which are both commonly used, doing wildly different things and thus potentially causing hard-to-track-down bounds errors is a recipe for disaster.

[1player]

Also as a newbie, if I were to encounter this line from the FAQ:

int[] b = a[3..6]; // Or a[3:4]

This is just impossible to parse and figure out how long the slice is if I haven't committed to memory that "colon means len, two dots means end, or perhaps this is a bug and should be the other way around. Who knows?!".

[lerno]

They are mostly for different uses. The range syntax is predominantly used for ranges outside of slices:

switch (foo)
{
   case 2..5: io::printn("2-5");
}

In this case we want an inclusive range. Similar with designated initializers:

int[5] x = { [2..3] = 4 };

However, once we slice, then : is the more common choice since we typically want to grab a number of characters from a certain offset.

We can note that start:len lacks clarity in those cases:

switch (foo)
{
   case 2:4: io::printn("2-5");
}
int[5] x = { [2:2] = 4 };

I can only draw the conclusion that there is no way to make this more welcoming to users and it's an irreducible complexity.

[1player]

Is it irreducible complexity? Many languages make do with just the [start..end] syntax. If you know the length, nothing stops you from doing [start..(start+len)]

[lerno]

That is assuming exclusive ranges with ... However, as we've seen above, such ranges would be a poor match for cases and designated initializers.

Not that this is building on the GCC extension with ... for ranges. Something which is up for proposal in C2y. So I think it's clear that inclusive ranges is the C-like thing to do.

With this firmly decided by established C patterns (that is, we need an inclusive range syntax), the only thing that remains is to decide how to handle exclusive ranges and start + length, which then requires different syntax.

If using start-length, that should naturally not share .. similarities due to its different semantics. : is the natural choice. The other possibility would be to introduce ..< or or similar for exclusive ranges. Having two different ranges is in Swift and Ruby to take some examples.

However, this is very inefficient in x[start..<start + len] patterns, as those are often on the form of x[get_offset()..get_offset() + len] which would be two calls. To avoid this, Zig uses the pattern x[get_offset()..][..len] in absence of x[start:len] syntax.

My estimate is that start:len is more common than start..<exlusive_end in use. In other words it makes more sense to support start:len than start..<exclusive_end

The question is then whether ..< should exist as well, giving 3 different operators.

In my estimate the answer is "no". ..< makes more sense if the language actually uses the ranges for other things than slicing. For example Odin and Zig uses this for iterating over a range. C3 doesn't have this, which makes it fairly superfluous.