Add sugar v[a .. b] be sugar for vec.slice and str.slice

[erickt]

** UPDATE by @nikomatsakis **

Closed in favor of this RFC repo issue: rust-lang/rfcs#13

** ORIGINAL **

@graydon said in irc today:

graydon: I would like foo[a..b] to work for slicing, tbh
graydon: I mean, if the square brackets (arguably some of the nicest symbols available in ascii) are stolen for vecs, we might as well use them as thoroughly as we can

[brendanzab]

What about having some sort of sugar for str.len()? D allows you to use $ in index and slice operators to specify the length of the arrays. Eg:

// These expressions are equivalent:
bar[]
bar[0 .. 4]
bar[0 .. $]
bar[0 .. bar.length]

Also (from this article):

int[] c = a[$-2..$]; // c refers to the last two elements of a
                     // ($ stands for length inside a slice or index operation).

D also allows you to overload the slice and slice assignment operators. The nice thing about being able to overload those operators would be that you'd be able to implement vector slicing in core, as opposed to it being some compiler magic.

[Dretch]

How about copying the python syntax (http://stackoverflow.com/questions/509211/good-primer-for-python-slice-notation).

I.e (in python):

a[start:end] # items start through end-1
a[start:]    # items start through the rest of the array
a[:end]      # items from the beginning through end-1
a[:]         # a copy of the whole array

[brendanzab]

That's a decent idea. So start and end would be new keywords? That's the only bummer.

[kud1ing]

start and end are just variable names in the Python example. I think the suggestion is that if you don't give an index, it either stands for 0 or length() - 1.

[brendanzab]

Oh, silly me. Yeah I see. That seems like an elegant solution.

[jruderman]

+1 for copying the Python syntax.

+1 on the Python syntax (including negative indices to specify offsets from the end of the vector). It would also be nice to allow the operator to be overloaded (e.g., trait Slice<From, To, Result>) for things like sorted sets.

[jruderman]

Special interpretation of negative numbers scares me. It sounds both slow (requiring a branch) and dangerous (you expected a crash, but instead you got the last element of the array). I prefer D's approach.

[mneumann]

I also prefer the D syntax using ... This is also the same syntax as in match range patterns. I don't think leaving off the first component (like in Python arr[:9]) makes much sense, as it can be simply written as a 0. Using $ as the length also makes absolute sense to me. I am thinking of it as in a regular expression. Python uses a : because it has an additional step element, and I think Python always copies slices because of this.

[brendanzab]

The issue with using $ is that it conflicts with macros.

[sanxiyn]

Does # work?

[mneumann]

For the rare case that we would need $ in a macro, couldn't it be escaped in some way? What about this:

a[0:]     vec::view(a, 0, a.len())
a[0:3]    vec::view(a, 0, 3)
a[0:^1]   vec::view(a, 0, a.len()-1)

Here ^1 would mean without one element at the end. This has the advantage that we don't have to do the minus as in $-1 ourself and as such might prevent some casting issues (the end index could become negative). Similarily one could apply the same for the beginning a[^1:] would means "without the first element". The only advantage I would see here over plain a[1:] is that of non-zero indexed arrays (which we don't have of course).

[fabiand]

I also favor the python syntax, it comes very handy. Including using negative numbres to specify the offset from the end of an array. Does it really need a branch?

[graydon]

Prefer not to add $ or ^ support, nor a syntax different from ".." for ranges (which is currently supported in expression and pattern grammars, and may be worth using in type grammar rather than the current "* N"). 0 and foo.len() are ok for the explicit ends. Think simplicity and symmetry.

Keep in mind we now support restructuring vector patterns, which soaks up some of this feature.

[jruderman]

I don't like using foo.len() for the end because it's easy to mess up, and because foo might be a complicated expression I don't want to repeat.