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
