On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than "lets keep using ~[T]" and ~[T] & &[T]
having the same in-memory representation (covered below).
Under any scheme I can think of, there are negatives:
1. without calling shrink_to_fit in the conversion, we lose the ability
to have sized deallocations (covered by others in this thread)
2. if we do call it, then anything returning a ~[T] after building it
with a Vec<T> is unavoidably slower
3. either way, you're throwing away (the knowledge of) any extra
capacity that was allocated, so if someone wishes to continue extending
the slice returned by e.g. `foo`, then `let v = foo().into_vec();
v.push(1)` will always require a realloc. (And for library functions, we
shouldn't be dictating how people use the return values.)
4. it adds two vector-like types that someone needs to think about: in
the common case the benefits of ~[] (one word smaller) are completely
useless, it's really only mostly-immutable heavily-nested data types
with a lot of vectors like Rust's AST where it helps[1]. I.e. almost all
situations are fine (or better) with a Vec.
5. how will the built-in ~[] type use allocators? (well, I guess this is
really "how will the built-in ~ type use allocators?", but that question
still needs answering[2].)
On the representation of ~[T] and &[T] being the same: this means that
theoretically a ~[T] in covariant(?) position can be coerced to a &[T],
e.g. Vec<~[T]> -> Vec<&[T]>. However, this only really matters for
functions returning many nested slices/vectors, e.g. the same Vec
example, because pretty much anything else will be able to write
`vec.as_slice()` cheaply. (In the code base, the only things mentioning
/~[~[/ now are a few tests and things handling the raw argc/argv, i.e.
returning ~[~[u8]].)
I don't think this should be a major concern, because I don't see us
suddenly growing functions a pile of new functions returning ~[~[T]],
and if we do, I would think that they would be better suited to being an
iterator (assuming that's possible) over Vec's, and these internal Vec
can be then be mapped to ~[T] cheaply before collecting the iterator to
a whole new Vec<Vec> (or Vec<~[]>) (assuming a &[Vec]/&[~[]] is wanted).
I'm concerned we are wanting to stick with ~[T] because it's what we
currently have, and is familiar; as I said above, I don't see many
positives for doing it for library functions.
What about strings? Should we be using `StrBuf` as well?
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
