在 2013年11月19日 下午8:44，"Daniel Micay" <danielmi...@gmail.com>写道：
>
> On Tue, Nov 19, 2013 at 7:35 AM, spir <denis.s...@gmail.com> 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.
>
Are you telling us "~T is not ~T", just as "sun is not sun" and "moon is
not moon"?? If they do not have the same semantic, why use the same syntax?
> 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
> 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
