I've only skimmed this conversation, but note that the "specialness" of the 'self lifetime will be going away in the future.
On Mon, Sep 30, 2013 at 10:48 AM, Oren Ben-Kiki <[email protected]> wrote: > I see what you mean about the macro - it would get quite complex though. > > Regardless of macros, neat extensions with GC heaps and arenas and so on... > > I still find it surprising that it is flat-out impossible to explicitly > name the "default" lifetime of a struct, and also that the natural name for > this lifetime ('self) is used for an entirely different purpose. > > It would be nice if we could rename the existing 'self to something > (anything :-) else, and allow 'self to be used in struct field types and > elsewhere for the more natural (and currently unavailable) "lifetime of the > current struct". Yes, this comes with some limitations, but it is useful > for some interesting cases and its lack of an explicit name seems arbitrary > (it is the default in many cases, after all). > > At any rate, I now have a better grasp of what is going on, so I have a > better chance of writing code that actually works :-) > > Thanks for the explanations! > > > On Mon, Sep 30, 2013 at 5:34 PM, Steven Blenkinsop <[email protected]>wrote: > >> On Monday, 30 September 2013, Oren Ben-Kiki wrote: >> >>> Yes, it is very much like an arena... And yes, the idea is that all the >>> pointers are contained in it, so the ~arena as a whole should be safe to >>> send, but that contradicts using @ - maybe it could be re-written using >>> Rc... hmmm. At any rate, thanks for the pointer - I wasn't aware of arenas >>> before. >>> >>> Another hmmm... An arena sounds a lot like a weak version of a GC-ed >>> heap... So here's a thought: What if @ pointers had a heap associated with >>> them, just like & pointers have a lifetime? We have the task-global @ heap, >>> and we have the static & lifetime... but we can explicitly manage & >>> lifetimes - how about if we could explicitly create a new Gc-heap use it to >>> happily muck about with @'my-heap pointers (which would be statically >>> prevented from being mixed with @'other-heap pointers), and be able to send >>> the whole heap between tasks, etc.? (Not that I necessarily suggest @'heap >>> as a syntax, but you get the idea) >>> >>> Gc would still run in the context of one heap at a time... but this >>> would remove the restriction of one task <=> one heap. >>> >> >> This would be neat, yes. In this case, accessing such a heap would be >> conceptually identical to temporarily joining a task, except without the >> overhead of having to schedule it, since it would have no independently >> executing code. Figuring out how to hook it into the GC would be a neat >> trick... >> >> As for what a macro would expand to, I was thinking more that it would >> expand to the containing structure and some smart references that use >> lifetimes to ensure that the containing structure is pinned during their >> existence and that they don't outlive it. You'd have to interact with it >> using methods which make sure you can't break any of the invariants, such >> as aliasing something and then trying to freeze it. To what extent you >> could do this statically rather than dynamically, I'm not sure, but >> lifetimes are a fairly powerful concept, so it's plausible one could work >> something out. Doing it dynamically would basically mean using Cells >> modified to have lifetimes as the smart references into the structure. It >> would be nice to have a version of the smart references that ensured you >> didn't externally alias something which is also externally mutable, though. >> > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
