<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 8, 2013 at 6:33 AM, Niko Matsakis <span dir="ltr"><<a href="mailto:niko@alum.mit.edu" target="_blank">niko@alum.mit.edu</a>></span> wrote:<br>






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



<br>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).<br>



<br></div><div>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.<br>




</div></div></div></div>