unifying slicing_syntax and range function

[oli-obk]

Right now there are two ways to get a slice. Through the slice syntax, and through the slice function.
I suggest changing the slice function to take a single &Ranged argument. Ranged is a new trait somewhere along these lines:

trait Ranged {
  fn begin(&self) -> Option<uint>;
  fn end(&self) -> Option<uint>;
}

And changing the slicing_syntax to create a temporary Range object that has both the iterator trait and the Ranged trait.

let x = [99i8, 10, 15, 6];
// current syntax
let a = x[1..3];
let b = x.slice(1, 3);
// hypothetical syntax:
let c = x.slice(1..3);
// and this would work, too
for i in 1..3 {
    println!("test: {}", i);
}

The new slice function would look somewhat like this:

fn slice<'a>(&'a self, range: &Ranged) -> &'a [T] {
    match (range.begin(), range.end()) {
        (None, None) => {self.old_as_slice()}
        (None, Some(x)) => {self.old_slice_to(x)}
        (Some(y), None) => {self.old_slice_from(y)}
        (Some(y), Some(x)) => {self.old_slice(y, x)}
    }
}

here's a list of slice_syntax examples mapping to range function calls:

n..m -> range(n, m)
..m -> range_to(m)
n.. -> range_from(n)

no actual empty range exists, but n..m for m <= n would cause an empty range to be created, as it currently happens with the slicing_syntax, too.

[kevinmehall]

This is similar to the proposal in RFC #439.

[oli-obk]

i didn't really mention this properly: I don't suggest a forced conversion of a range notation to a range object. It should instead be like an int/float literal declaration without a fixed type.

let r = 2..4;
for i in r {
  println!("test: {}", i);
}
let x = [99i8, 10, 15, 6];
let a = x[r]; // error, is already a range iterator
for j in r { // error, iterator already used up? or by copy?
}

this would allow the syntax to be used in the future for new things.
For example the loop could check for out of bounds at compile time. Or a special syntax could check if an integer or float value is in a specific range. If the range notation were always converted to a specific type this would cause problems in the future.