re life time management this may help https://github.com/mozilla/rust/wiki/Proposals
see Proposal for regions which is implemented Also interesting discussion on variable stacks in last weeks meeting https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-07-09 and you can see the project is active which is why the doco is always out of date. . https://github.com/mozilla/rust/pulse "How much of that utterly bizarre complexity would go away with proper region typing? 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. " Like i said a fork has potential.... It is less of a research project and more of an engineering get something out now to improve C , if the GC improves then the custom pointers become redundent .. if not then they allow custom work. On Tue, Jul 16, 2013 at 7:31 AM, Jonathan S. Shapiro <[email protected]>wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
