radical ideas about GC and ARC : need to be time driven?

[via Digitalmars-d]

On Tuesday, 13 May 2014 at 07:12:02 UTC, Marco Leise wrote:
> Am Mon, 12 May 2014 08:44:51 +0000
> schrieb "Marc Schütz" <schuetzm at gmx.net>:
>
>> On Monday, 12 May 2014 at 04:22:21 UTC, Marco Leise wrote:
>> > On the positive side the talk about Rust, in particular how
>> > reference counted pointers decay to borrowed pointers made me
>> > think the same could be done for our "scope" args. A 
>> > reference
>> > counted slice with 3 machine words could decay to a 2 machine
>> > word "scoped" slice. Most of my code at least just works on 
>> > the
>> > slices and doesn't keep a reference to them. A counter 
>> > example
>> > is when you have something like an XML parser - a use case
>> > that D traditionally (see Tango) excelled in. The GC
>> > environment and slices make it possible to replace string
>> > copies with cheap slices into the original XML string.
>> 
>> Rust also has a solution for this: They have lifetime 
>> annotations. D's scope could be extended to support something 
>> similar:
>> 
>>      scope(input) string getSlice(scope string input);
>> 
>> or with methods:
>> 
>>      struct Xml {
>>          scope(this) string getSlice();
>>      }
>> 
>> scope(symbol) means, "this value references/aliases (parts of) 
>> the value referred to by <symbol>". The compiler can then make 
>> sure it is never assigned to variables with longer lifetimes 
>> than <symbol>.
>
> Crazy shit, now we are getting into concepts that I have no
> idea of how well they play in real code. There are no globals,
> but threads all create their own call stacks with independent
> lifetimes. So at that point lifetime annotations become
> interesting.

I don't really know a lot about Rust, but I believe this is not 
an issue with Rust, as its variables are only thread-local. You 
can send things to other threads, but then they become 
inaccessible in the current thread. In general, lifetime 
annotations can only be used for "simple" relationships. It's 
also not a way to keep objects alive as long as they are 
referenced, but rather a way to disallow references to exist 
longer than the objects they point to.