add new vector representation as a library

[thestinger]

This is just an initial implementation and does not yet fully replace ~[T]. A generic initialization syntax for containers is missing, and the slice functionality needs to be reworked to make auto-slicing unnecessary.

Traits for supporting indexing properly are also required. This also needs to be fixed to make ring buffers as easy to use as vectors.

The tests and documentation for ~[T] can be ported over to this type when it is removed. I don't really expect DST to happen for vectors as having both ~[T] and Vec<T> is overcomplicated and changing the slice representation to 3 words is not at all appealing. Unlike with traits, it's possible (and easy) to implement RcSlice<T> and GcSlice<T> without compiler help.

[emberian]

+1 yes plz

[olsonjeffery]

golf claps

[alexcrichton]

Nice work!

We should probably discuss this before merging.

[pcwalton]

I don't understand what "I don't really expect DST to happen for vectors" means. This pull request uses slices, after all. Slices are just a special case of DST.

Regardless, this PR looks good to me.

[thestinger]

@pcwalton: As in unlike traits, stuff like GcSlice/RcSlice is easy to implement with library types. I'm worried that having both ~[T] and a Vec<T> type with a capacity will be too complex as both can be grown. It's obviously essential for traits but I still prefer just using plain library types for vectors and the built-in fixed-size arrays and slices.

[brson]

The intent is that ~[T] won't have a capacity under DST. It will simply be a boxed, "unsized" array, pointer plus length.

[thestinger]

@brson: I know, and I think it would be simpler to have a single owned vector type. It's true that a 2-word representation could probably save memory in some cases, and having [T] as a DST would make any smart pointer have a vector type automatically but I don't think more than GcSlice<T> and RcSlice<T> would be necessary if it was done by hand.

[pcwalton]

What about &[T]? That's a dynamically sized type too.

[thestinger]

@pcwalton: It could just remain as it is now though.

(anyway I fine with doing both, I just didn't the end decision would end up adding [T] after all - shouldn't have mentioned it here :P)

[alexcrichton]

I also have concerns about Vec<T> and ~[T], because it seems to me like you wouldn't actually end up using ~[T] that often. It does kinda make sense that ~[T] is a type in the typesystem, but it seems that &[T] would be the primary use case for sigil + [T].

Regardless, everything I understand about DST means that ~[T] is not a growable vector, and we'll of course always need one of those. It also sounds like we'll want DST, so it sounds like it's inevitable that we're going to have a Vec implementation which looks like this.

Are there any objections to merging this now?