Because the other range types have dedicated syntax and are usable as first-class values in custom APIs. Not having FullRange is inconsistent.
Motivation
Slicing syntax is neat, it gives us ranges and slices using one syntax device, ...
We can already use the Range, RangeTo, RangeFrom values to create custom interfaces:
trait AnyRange<Idx> {
// Imagine all the Range types implement this trait
}
struct Mat {
data: Vec<f32>
}
impl Mat {
fn slice<R, S>(&self, xs: R, ys: S) -> Mat where
R: AnyRange<uint>, S: AnyRange<uint>
{
// Implement 2D slicing here.
// Maybe the type is even CoW and returns a view transparently?
}
}
With the slice syntax, we can implement things like:
let m = Mat::new(...)
let submatrix = m.slice(1.., 1..);
But FullRange is missing syntax! We can’t do this today:
let submatrix = m.slice(1.., ..);
Workarounds?
We can use 0.. instead of .., in almost all cases.
I was just looking at the implementation of .. parsing for #20811. I don’t think that this would cause any ambiguities, and it should by trivial to implement.
Of course, this would add yet another way to borrow the contents of a String.
&*s, s.as_slice(), &s[], &s[..], in the future possibly &s with deref coercions.
pcwalton stressing breaking changes only is correct, but if we want to fix this with consistency, it is breaking because it wants &buf[] to become &buf[…]
There is no way we are going through another round of break-the-world changes just to avoid this relatively minor case of overlap between &foo[..] and &foo[]. Besides, I think that converting to a slice is sufficiently common that it warrants extra sugar.