Implement overloaded slice notation

[alexcrichton]

Tracking issue for rust-lang/rfcs#198

[alexcrichton]

Nominating, I believe this is a very important syntax to have.

[alexcrichton]

cc #17177, this may just be a dupe of that.

[aturon]

@alexcrichton This is #17177 :-)

Note that if we end up making Vec<T> deref to [T], the need for the [] notation becomes less pressing.

[alexcrichton]

oops: cc #14983

[pnkfelix]

We can add this syntax backwards-compatibly.

Assigning P-low, not 1.0 blocker.

[nrc]

I am implementing

[aturon]

@nick29581 Awesome!

[nrc]

See #17293 and #17273 for some work left to do.

[nrc]

and #17295

[nodakai]

@nick29581 You listed three issues #17293 #17273 and #17295 but only the first among them is still open. Is that the reason why we still need feature(slicing_syntax) for this syntax?

[nrc]

@nodakai in general, feature gates are required until we are absolutely sure that a feature should be in Rust and stay in its current form. We are not there yet with slicing notation. In fact, we are tweaking the implementation and the surface syntax at the moment (see #19795).

[nodakai]

@nick29581 I see, so the slicing notation is tracked by 0439-cmp-ops-reform rather than 0198-slice-notation now.

[nrc]

@nodakai I wouldn't say either RFC tracks slicing notation - both contain aspects of the design