[rust-dev] About owned pointer

Daniel Micay danielmicay at gmail.com
Fri Nov 8 04:39:59 PST 2013

On Fri, Nov 8, 2013 at 6:33 AM, Niko Matsakis <niko at alum.mit.edu> wrote:

> On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote:
> > It's so confusing. If it's not owned box, why not remove ~? Make "str"
> > default be dynamic should OK.
> I am not sure why Daniel says that a `~str` or `~[]` is not an "owned
> box". I guess he's using the term in some specific way. I consider
> `~str` and `~[]` to be exactly the same as any other `~T` value in
> usage and semantics. They are allocated on the same heap, moved from
> place to place, and freed at the same time, etc.
> The difference between a type like `str` or `[T]` and other types is
> that `str` and `[T]` are actually a series of values: `u8` bytes and
> `T` values respectively. This entails a change in representation and
> is also the reason that one *must* use a pointer to refer to them,
> because the number of values is not known and hence the compiler can't
> calculate the size of the value.
> Note that we are to some extent evolving how we handle dynamically
> sized types like `str` and `[]`. Right now they are quite second class
> (you can't impl them etc) but that will change. Nonetheless, it will
> remain true that you can never have a *value* of type `str` or `[]`,
> but most always use a pointer (either `~[]` or `&[]`).
> Also note that a type like `~[T]` is in fact going to be represented
> not as a single pointer but rather three pointers, thanks to work by
> Daniel in fact.
> Niko

By owned box I just mean a type you can pass to `fn foo<T>(x: ~T) { }`
rather than something that's owned and has a heap allocation. Most of the
other containers (hashmap, treemap, trie, ringbuf, priority_queue) are also
owned, sendable and have a destructor.

In my opinion, it would be better to have stronger support for library
containers and only have vector/string slices built-in to the language.
Stronger support would entail generic container literals, overloading
auto-slicing and a rooting API for the GC (when we get one).

There are good reasons to write another vector type, such as allocator
support, optimizing for small vectors or ABI compatibility with a foreign
library's vector type to avoid copying between the API boundary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20131108/e6c61438/attachment-0001.html>

More information about the Rust-dev mailing list