On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote: > I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to represent such pointers (for example, 1 would suffice). This does impose some additional burdens on slice conversion and the like. This conversation has focused on low-level effects, which is important to understand, but I think the bigger question is: how do we WANT the language to look? Is it useful to have a distinct `Vec<T>` and `~[T]` or -- in our ideal world -- would they be the same? I think we can make the interconversion fast for the default allocator, but we should design for the language we want to use. I could go either way on this. In the kind of programs I write, at least, most vectors get built up to a specific length and then stop growing (frequently they stop changing as well, but not always). Sometimes they continue growing. I actually rather like the idea of using `Vec<T>` as a kind of builder and `~[T]` as the end-product. In those cases where the vector continues to grow, of course, I can just keep the `Vec<T>` around. Following this logic, I would imagine that most APIs want to consume and produce `~[T]`, since they consume and produce end products. On the other hand, I could imagine and appreciate an argument that we should just take and produce `Vec<T>`, which gives somewhat more flexibility. In general, Rust takes the philosophy that "if you own it, you can mutate it", so why make growing harder than it needs to be? Preferring Vec<T> also means fewer choices, usually a good thing. Perhaps the best thing is to wait a month (or two or three) until DST is more of a reality and then see how we feel. Niko _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
