On 02/04/14 02:28 PM, Patrick Walton wrote: > On 4/2/14 9:25 AM, Daniel Micay wrote: >> On 02/04/14 11:35 AM, Alex Crichton wrote: >>> I've noticed recently that there seems to be a bit of confusion about >>> the fate >>> of ~[T] with an impending implementation of DST on the horizon. This >>> has been >>> accompanied with a number of pull requests to completely remove many >>> uses of >>> ~[T] throughout the standard distribution. I'd like to take some time to >>> straighten out what's going on with Vec<T> and ~[T]. >> >> I think this is a difference of opinion, not "confusion". The original >> pull requests switching `~[T]` to `Vec<T>` were done by pcwalton, and >> this was with full knowledge of the plans for `~[T]`. > > It was transitionary. I thought that we would have to fully extract > `~[T]` from the language before DST would work, but it now seems likely > that that won't need to happen. > >> The `~[T]` type will exist because `[T]` will exist as a type. It won't >> be an explicit choice to support having it. Some of us consider it an >> unfortunate consequence of DST rather than a useful type. > > Even if you buy that `~[T]` is useless (which I'm not sure I do), it's > no more unfortunate than the fact that the type system allows useless > types like `Rc<Rc<Rc<int>>>` is unfortunate.
No one is proposing that we use `Rc<Rc<Rc<int>>>` in the standard library. Using `~[T]` instead of migrating to `Vec<T>` means there will be conversion noise where there was not going to be conversion noise before. >> If `~[T]` remains used throughout the libraries, Rust will become >> noisier than languages like C++ with a unified vector type. The need to >> convert between `Vec<T>` and `~[T]` would add noise to lots of code, >> without any adding measurable optimization win. A micro-optimization >> shouldn't drive the design of the libraries, especially when it will >> prevent making a significant *macro*-optimization (passing a length to >> the deallocation function). > > In practice C++ libraries use their own custom vector types all over the > place, so I wouldn't say that Rust is going to be significantly noisier > no matter what we do. Interoperability between different libraries is > not a strong point of C++. > > Besides, C++ has this too, with `unique_ptr<T[]>`. This Stack Overflow > answer is actually pretty illuminating: `std::unique_ptr<[T]>` is useful because lots of legacy code uses the new[]/delete[] memory allocations. Unique pointers also take a custom deleter parameter, because they're usable for managing stuff like files, etc. in C++. > I think that length-frozen owned vectors are likely to be surprisingly > common. We'll see. They'll certainly be common if the standard library forces many conversions to and from `Vec<T>`... It should not be stated that this conversion is free though, because it only remains free as long as you're using a legacy allocation API like `malloc`. It's also not free in terms of language complexity - people are going to wonder when they should use each one, and I know I'm certainly going to be telling people to use `Vec<T>` almost everywhere.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
