First Draft: ref For Variable Declarations

[Richard (Rikki) Andrew Cattermole]

On 13/04/2024 9:42 AM, Walter Bright wrote:
> On 4/12/2024 2:16 PM, Richard (Rikki) Andrew Cattermole wrote:
>> - "Enable local variables do be declared as ref."
>>
>> s/do/to/
>>
>> - Are they automatically scope as well?
> 
> Scope would apply to what the ref points to, not what the ref is.

So this is introducing a non-transitive scope.

>> - So this doesn't support borrowing from a data structure?
>>
>> Why not?
> 
> Inability to control the lifetime.

This sounds like a consequence due to not having scope on the variable.

Hmm, non-transitive scope, now that I'm thinking about this, it seems 
like the limitation is in the lack of DFA, not in the type system. 
Another thing for type state analysis DFA I suppose.

>> Closing what I call DIP1000's last big hole, would allow this.
>>
>> ```d
>> DS ds = ...;
>> Wrapper wrapper = ds[...];
>> ref item = wrapper.get;
>>
>> wrapper.destroy;
>> item.writeln; // error
>> ```
>>
>> This would be awesome to have.
> 
> Since you can pass wrapper.get to a ref parameter to a function, this 
> already works.

Ugh what?

wrapper died, item still alive.

You shouldn't be able to access item after that.

This would likely be the primary use case to using ref on a variable 
declaration and people will try it as soon as they learn they can put 
ref on a variable.

>> - What is the point of this if the previous point isn't it?
> 
> ??
> 
>> An alias would be more appropriate for the example given.

The argument made isn't compelling for it to only act as an alias to 
other variable declarations.

Borrowing memory from other variables will be attempted, and will be 
attempted often and that will cause frustration as an obvious feature 
isn't supported.