I agree ----- Gaetan
2013/11/8 Diggory Hardy <li...@dhardy.name> > On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: > > 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. > > What's wrong with sticking with convention here? E.g. C++'s `string` and > `vector<T>` are objects containing two or three pointers. D's arrays and > `string` act the same way. Even C's dynamic arrays (`int x[]`) can be > thought > of the same way (if one avoids thinking of them as pointers). > > So why not consider `str` and `[T]` conglomerates of a fixed size > containing > the pointers (start, length and capacity or whatever) needed? Semantically > it's the same while syntactically it's simpler. > > Slices will need new names of course, but I think the resulting decrease in > confusion will be worth it. (D's developers tried to go the other way, with > all arrays and slices being effectively copy-on-write slices, before > realising > that discrete array/slices types _were_ needed.) > > DH > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
