DIP69 - Implement scope for escape proof references

[deadalnix via Digitalmars-d]

On Friday, 5 December 2014 at 00:32:32 UTC, Walter Bright wrote:
> On 12/4/2014 3:04 PM, deadalnix wrote:
>> So as mentioned, there are various problem with this DIP :
>>  - rvalue are defined as having a scope that goes to the end 
>> of the statement.
>> That mean they can never be assigned to anything as per spec.
>
> I don't believe this is correct. Rvalues can be assigned, just 
> like:
>
>    __gshared int x;
>    { int i; x = i; }
>
> i's scope ends at the } but it can still be assigned to x.
>

It work even better when i has indirections.

>>  - It add more special casing with & (as if it wasn't enough 
>> of a mess with
>> @property, optional () and the fact the function aren't first 
>> class). For
>> instance *e has infinite lifetime when &(*e) is lifetime(e).
>
> That's right. I know you're worried about that, but I still 
> don't see it as an actual problem. (The optimizer makes use of 
> this special case all the time.)
>

Yes, this is the job of the optimizer to do this kind of stunt.
Not the semantic analysis.

>> Also, considering *e has infinite lifetime, (but not e[i] ???)
>
> e[i] should be same as *e, unless e is a literal or tuple.
>

Ho I missed the *. Sorry for that.

>> what is the point of scope at all ? If all indirection goes to 
>> infinite lifetime (ie GC) then
>> lifetime only apply to local variable and it should not be 
>> able to escape these,
>> scope or not.
>
> I originally had scope only apply to ref, but that made having 
> scoped classes impossible.
>

Promoting scoped class on stack is an ownership problem, and out
of scope (!). It make sense to allow it as an optimization.

Problem is, lifetime goes to infinite after indirection, so I'm
not sure what the guarantee is.

>
>> During discussion, I proposed to differentiate lifetime 
>> calculation between
>> lvalues and rvalues (which are inherently different beasts 
>> with different
>> lifetime) and carry (or not) the scope flag with each 
>> expression.
>
> I'm not sure how that would be different from the DIP as it 
> stands now.

I cause everything reached through the view to be scope and
obliviate the need for things like &(*e) having special meaning.