Ah. I found the Rust blog post entitled "An Overview of Memory Management
in 
Rust<http://pcwalton.github.io/blog/2013/03/18/an-overview-of-memory-management-in-rust/>".
Unless other pointers have subsequently been invented, Rust seems to have
several pointers and one library mechanism for managing lifetimes:

1. Managed pointers (the article calls this a "managed smart pointer") that
references GC'd storage. These are denoted by @T, where T is a type name.
2. Unique pointers, denoted by ~T. These are pointers to objects that are
destroyed when the unique dominant pointer goes out of scope.
3. Something that they call "borrowed pointers", which are a limited form
of region-inferred pointer. A borrowed pointer can appear at any function
argument.
4. reference-counted pointers that are managed as a library function. It
isn't clear to me how these get built from the existing language primitives.

I've seen references in other documents on Rust to weak pointers as well.

Unique pointers are not the same as linear references; they can be viewed
as a degenerate case, though that doesn't appear to be the intent of the
Rust design.

Observations:

1. The syntactic distinction between unique pointers and managed pointers
is unnecessary; the appropriate type can be inferred by [conservative]
escape analysis. It probably *is* useful to have a way to specify the
programmer's intent, but in most cases the distinction probably shouldn't
appear in source code.
2. Their "borrowed" pointers aren't a new idea. In fact they are a trivial
space optimization on "IN by-reference" parameters. The same optimization
is implemented transparently by the BitC compiler; it wasn't novel enough
to be worth mentioning as part of the semantics. The BitC mechanism is
actually more general, since non-escaping bindings can be introdouced at
any LET binding. This wasn't an originally intended feature; it was a side
effect of the LET-rewriting pass. Once in place, it surfaced as a language
commitment.




On Mon, Jul 15, 2013 at 4:02 PM, Jonathan S. Shapiro <[email protected]>wrote:

> On Mon, Jul 15, 2013 at 3:29 PM, Jon Zeppieri <[email protected]> wrote:
>
>> Then, here is a proposal to go in a different direction:
>>
>> http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/
>
>
> Arrgh! That blog post points at *so* many language features that aren't
> present in the Rust reference. Is there someplace I can go to learn more
> about the rust mutti-heap memory model?
>
> How much of that utterly bizarre complexity would go away with proper
> region typing?
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to