rustc: Remove ~[T] from the language

[alexcrichton]

The following features have been removed

• box [a, b, c]
• ~[a, b, c]
• box [a, ..N]
• ~[a, ..N]
• ~[T] (as a type)
• deprecated_owned_vector lint

All users of ~[T] should move to using Vec instead.

[sfackler]

When you say that box [a, b, c] and box [a, ..N] have been removed, are they actually errors or do they just return Box<[T, ..N]> (maybe Box<&[T]>)?

[alexcrichton]

For now they both signal a parser error, but after awhile I'd like to remove the parser hacks and allow them to become Box<[T, ..N]>. I just wanted to remove them to completely purge this type of vector from the language so we have a clean state to add it back in.

[sfackler]

Sounds good to me.

[huonw]

I was under the impression this was meant to be a long term thing?

[alexcrichton]

As with Box<[T, ..N]>, I figured this could be added back in a principled manner once DST landed. Do you think we should leave the trait definition for now?

[huonw]

I'm fine with it disappearing... if there's a need for it in future then it can reappear then.

[huonw]

Nice diffstat. ❤️

[nrc]

I'm in the middle of doing this properly for the DST work. I find it useful to preserve existing behaviour rather than rip it out and start again (in particular, there are bugs I've found purely because we have this stuff in the libraries and which we did not have tests for, I'm sure it will happen again). Is there any urgency for doing this right now?

[chris-morgan]

@nick29581 The existence of both ~str and String and both ~[T] and Vec<T> is certainly confusing people. (More the former pair than the latter, but confusion about the latter is still certainly palpable.)

[alexcrichton]

I'd like to take the same route as ~str and add back in Box<[T]> in a more principled fashion after some more dust has settled with Vec<T>. I'm not convinced that the public-facing api components of ~[T] are what we want to keep into the future anyway.