On 02/04/14 03:13 PM, comex wrote: > On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay <danielmi...@gmail.com> wrote: > > But is that really worth hanging language features on, one > way or the other?
This also isn't the only optimization lost here. Zero-size allocations will need to be clamped to one if passing a size to free isn't required. Why? Rust uses a non-nullable pointer optimization, where Option<~T> and similar enums can be stored without a tag. This optimization should also be extended to types like slices in the future. It applies to the current `~[T]` but would need to be adapted to a new representation. It's important to avoid allocating for a zero-size allocation, in order to save memory for ~Trait with zero-size types and to avoid allocating in zero-size vectors. However, this means that a zero-size allocation needs to be represented as non-null. Rust needs a way of knowing that despite being non-null, there is no allocated capacity. For example, consider a 0-size slice: (0x22, 0) When this is passed to `free`, Rust needs to be sure that a 0-size slice also has a 0-size capacity. In order to do that, shrink_to_fit() needs to happen during Vec<T> -> ~[T] conversions. At the moment, Rust is completely broken in this regard. The following expression evaluates to None: Some(~()) I have no sane proposal to fix this beyond passing a size to free.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
