On Tue, Nov 19, 2013 at 7:35 AM, spir <[email protected]> wrote:
>
> If this is all true, that recursive structures are the main, "almost the
> only use case" of ~ pointers, then the tutorial is in my view rather ok on
> this point. But then, why does it seem there are ~ pointers in every corner
> of Rust code? Including numerous cases in the tutorial itself.
>
> Also, how would we explain and term this meaning? "Indirection" is not good
> enough (for we introduce indirections for other reasons, if only to have
> variable-size content). I'd say "self-similarity" is the right term here,
> and self-explaining (see wikipedia if you are not familiar with the idea).
> This is, in fact, the actual idea commonly termed "recursivity" in
> programming (wrongly, in my view, but this is yet another terminological
> issue). A rule about ~ pointers thus may be:
>
> Whenever one needs self-similarity, use a ~ pointer.
> This lets the language store the element through the kind
> of indirection that permits a self-similar structure.
>
> (I'm not happy of this formulation, neither, still obscure.)
>
> however, other comments on ~ pointers (eg comparisons with C++ unique_ptr,
> notes that it means owned or "my") introduce ideas rather different from the
> one you suggest here, don't they? Say I manually create a kind of string or
> "fix-size" array:
>
> struct String {
> n_bytes : uint,
> bytes : ~[u8],
> }
>
> struct Array <Item> {
> n_items : uint,
> items : ~[Item],
> }
The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).
The ~str and ~[T] types are *not* owned boxes in the current type
system. There has been a proposal for dynamically sized types which
would make them owned boxes, but I only like it as the path forwards
for traits/closures and not vectors.
I don't think dynamic arrays/strings belong as built-in types
hard-wired into the language, especially with a confusing syntax like
this. They should be treated as other containers are.
In what I think is a sane system, dynamic arrays would be a library
`Vec<T>` type just like we have `HashMap<K, V>` and will have other
vector types like `Rope<T>` or `SmallVec<T, N>`.
> Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway...
> If it is right, maybe the actual meaning of ~ is something like "proper
> content". Whenever a structure actually contains content which is actually
> proper to it, or more generally has (pointed) data participating to its
> description, then these contents or descriptive data should pointed with ~:
> because they belong / are proper to it.
>
> struct ComplexVisualForm {
> shape : ~ Shape,
> style : ~ Style,
> }
It doesn't make sense to use ~T over T without a reason to need a
pointer-size value. It offers nothing in terms of semantics. It uses
indirection to obtain pointer-size, and adds a destructor (a strict
loss in terms of functionality). If you're not writing a recursive
data structure or using dynamic dispatch via a trait object, you don't
need it.
> This matches my distinction between things and data (properly speaking).
> Data, even when pointed (for technological rather than semantic reasons),
> still belong to whatever they are part of. Data are never referenced
> (properly speaking), it makes no sense. Things instead exist by themselves,
> are always ref'ed, never copied (or moved), it makes no sense. If the
> reasoning above about ~ pointers is more or less correct (i doubt it is),
> then we have in Rust the proper kind of pointer to point to data, properly
> speaking, meaning information about things. Now, to reference things from
> multiple points of view, we need something else, proper refs or links, and
> they cannot be ordinary pointers (especially not GC'ed): we need true refs,
> independant from the data (while pointers hold their addresses).
>
> Denis
>
~T and T both have value semantics. Neither has by-reference
semantics, as ~T is always the unique owner of the contained value.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
