On 02/04/14 07:22 PM, Niko Matsakis wrote: > 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.
I used a sentinel value in my fix along with providing a guarantee that `free` is never called on zero-size allocation. That's the end of any no-op `Vec<T>` -> `~[T]` conversions since it will need to free a zero size allocation. It's not far from just calling `shrink_to_fit`, and allowing for passing a size to `free`. https://github.com/mozilla/rust/pull/13267 I don't think there's any way around without making `~ZeroSizeType` start allocating memory or losing the `Option<NonNullablePointer>` optimization otherwise. > 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. A distinct `~[T]` and `Vec<T>` will make the language more painful to use, so the only point I'm trying to counter is the performance one because it is *is* a valid micro-optimization in some cases. If our default allocation scheme takes advantage of a known size, then it will be faster. I don't think we should keep using a malloc/realloc/free-style API under the hood in the future. > 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. The language needs to be providing a significant safety/correctness guarantee or performance win in exchange for the extra noise and I don't really think it will be in general. There will be use cases for `~[T]` but I don't think they will be common. If an API consumes `~[T]`, it will lose track of capacity the caller may already be able to provide. If it produces `~[T]`, it will lose track of capacity the caller may want to use later on. > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
