DIP69 - Implement scope for escape proof references

[Dicebot via Digitalmars-d]

On Monday, 8 December 2014 at 23:19:26 UTC, deadalnix wrote:
> On Monday, 8 December 2014 at 20:54:54 UTC, Dicebot wrote:
>> But was there any reason why those traits (alien to type 
>> qualifiers) were pursued? What is the problem with `ref` 
>> simply meaning `non-null pointer` and allowing non-idempotent 
>> ref(ref(int))?
>
> Please no.
>
> when you do int a; and then use a, you always either refer to a,
> to memory storage (lvalue) or a, the value stored in that memory
> (the rvalue).
>
> When doing ref int a = xxx;
>
> You specify that you don't create a new storage for a, but that
> you must consider xxx as an lvalue, and bind the name a to that
> same lvalue.

My thoughts have went totally different direction:

ref(int) a = &xxx; // ok
ref(int) a = xxx; // bad, can't initialize ref from value
ref(int) a = intptr; // ok, implicitly inject assert(intptr)
ref(int) a = null; // bad, can't initialize ref from literal

Now I see how issue may arise because of implicit conversion to 
matching value type (when passing to as function argument for 
example) but we do already have structs with `alias this` which 
may need similar semantics - it needs to be defined anyway.

This is still offtopic. I support attempt to make scope a storage 
class in general because this is an approach of minimal change 
and still can be useful. Problem with defining it so that it 
actually is useful.