Convert all uses of vec::slice to vec::view

[bstrie]

16:38 <@nmatsakis> of course we plan to remove vec::slice()
16:38 <@nmatsakis> but no one has done it yet :)
16:39 <@nmatsakis> vec::view(x, 0, 5).to_vec()
16:39 <@nmatsakis> is basically equivalent to vec::slice(x, 0, 5) today
16:45 < bstrie> nmatsakis: is that the extent of the transformation required to go from slice to view?
16:46 <@nmatsakis> bstrie: I believe so
16:46 < bstrie> is vec::view also defined as a method on the same types that vec::slice is defined on?
16:47 <@nmatsakis> yes.

[graydon]

Huh. Maybe at an interface level, but I would quite like the resulting function to be called slice. I mean, the type that it returns is the slice type, &[], right? Seems like the correct term.

[nikomatsakis]

Yes, I think what we actuallly want to do is (1) replace vec::slice() with vec::view() and (2) rewrite existing uses of vec::slice() to use the pattern foo.slice().to_vec() if they actually need a new vector, and just foo.slice() if a slice will suffice.

[nickdesaulniers]

I'll tackle this if niko's suggestion is the consensus. Can someone assign this to me if it's good?

[bstrie]

Not sure what the status of this currently is, but in fact just today there was someone in the IRC channel who was halfway to reimplementing .view because .slice was doing the wrong thing. I'd say go ahead with it, seems like it wouldn't be entirely difficult to make this sort of mechanical change.

[nickdesaulniers]

So it sounds like they've already started on this bug?

[bstrie]

@nickdesaulniers no, I meant that they were accidentally reimplementing slices in their own code because they had thought that .slice was Rust's notion of a slice type, when actually .view is the canonical slice type. What I mean is that this issue should be settled ASAP to minimize the amount of confusion this continues to cause.

[nikomatsakis]

Nick, I can't seem to assign you, however I think there is no reason not
to start work on it.

[nickdesaulniers]

Are vec::view and and vec::slice being swapped, or are we discarding the current implementation of vec::slice and renaming vec::view to vec::slice?

[nikomatsakis]

I favor just having one method.

[nickdesaulniers]

Just to triple check; prior to any changes, the function signatures look like:

pub pure fn slice<T: Copy>(v: &[const T], start: uint, end: uint) -> ~[T];
pub pure fn view<T>(v: &r/[T], start: uint, end: uint) -> &r/[T];

and after:

pub pure fn slice<T>(v: &r/[T], start: uint, end: uint) -> &r/[T]

I've been working through necessary changes to other places that call slice or view. One issue I'm running into is a few functions such as tail:
https://github.com/mozilla/rust/blob/incoming/src/libcore/vec.rs#L227
which passes a first argument to slice of type: &[const T] but slice's new function signature from my patch requires the first argument to be of type &[T] so I get an error: mismatched types: expected &/[]but found&/[const 'a] (values differ in mutability). I don't think changing slice's new signature to take a borrowed reference to a vector of const T's is a good idea, since elsewhere in vector, there are warnings against passing that type to as_imm_buf:
https://github.com/mozilla/rust/blob/incoming/src/libcore/vec.rs#L1475

I don't think it would be a good idea for me to modify vec::tail, vec::tailn, vec::init, but I'm not in a position to make that call. Thanks in advance for the help!

[nickdesaulniers]

note: rename mut_view to mut_slice, and const_view to const_slice

[nickdesaulniers]

Tests are green for view -> slice rename. Rebasing, then renaming const_view and mut_view

[nickdesaulniers]

All done, tests are green. Going to rebase this once more and double check the tests, then pull request inbound.

[nickdesaulniers]

Tests green, pull request inbound

[nickdesaulniers]

This issue may now be closed. @brson

[brson]

\o/