On 03/04/14 10:22, 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.
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.
I don't think the basic routines returning vectors in libstd etc. are
producing end-products; they are fundamental building blocks, and their
output will be used in untold ways. (There are not many that consume
`~[T]`s by-value.)
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.
Are you thinking we should also wait before converting the current uses
of ~[T] to Vec<T>? Doing the migration gives us the performance[1] and
zero-length-zero-alloc benefits, but there were some concerns about
additional library churn if we end up converting back to DST's ~[T].
(I'd also guess doing a complete migration now would make the transition
slightly easier: no need for staging the libstd changes, and it would
allow the current ~[] handling to be removed from libsyntax/librustc
completely, leaving a slightly cleaner slate.)
Huon
[1]: https://github.com/mozilla/rust/issues/8981
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
