https://github.com/WalterBright/documents/blob/984374ca885e1cb10c2667cf872aebc13b4c1663/varRef.md

- "Enable local variables do be declared as ref."

s/do/to/

- Are they automatically scope as well?

- So this doesn't support borrowing from a data structure?

Why not?

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.

- What is the point of this if the previous point isn't it?

An alias would be more appropriate for the example given.

On 4/12/2024 2:34 PM, Lance Bachmeier wrote:
>> Decades of successful use have clearly demonstrated the utility of this form of restricted pointer.
> 
> It would be useful to expand on this. It obviously hasn't been used for decades in D programs if you're proposing it as a new language feature. I don't remember ever using it in any language.

It's been used as ref function parameters and foreach ref parameters, as mentioned in the DIP.

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 doesn't support borrowing from a data structure?
> 
> Why not?

Inability to control the lifetime.

> 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.


> - What is the point of this if the previous point isn't it?

??

> An alias would be more appropriate for the example given.

??

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.

On Friday, 12 April 2024 at 20:43:50 UTC, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/984374ca885e1cb10c2667cf872aebc13b4c1663/varRef.md

Finally, this is really needed to avoid unnecessary copys!

C# can also be added to prior work.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/declarations#reference-variables

On Friday, 12 April 2024 at 21:39:59 UTC, Walter Bright wrote:
> On 4/12/2024 2:34 PM, Lance Bachmeier wrote:
>>> Decades of successful use have clearly demonstrated the utility of this form of restricted pointer.
>> 
>> It would be useful to expand on this. It obviously hasn't been used for decades in D programs if you're proposing it as a new language feature. I don't remember ever using it in any language.
>
> It's been used as ref function parameters and foreach ref parameters, as mentioned in the DIP.

Then you're missing the very important qualification that they've been used successfully in other contexts. That doesn't provide evidence relevant to this proposal.

On 4/13/2024 6:06 AM, bachmeier wrote:
> On Friday, 12 April 2024 at 21:39:59 UTC, Walter Bright wrote:
>> On 4/12/2024 2:34 PM, Lance Bachmeier wrote:
>>>> Decades of successful use have clearly demonstrated the utility of this form of restricted pointer.
>>>
>>> It would be useful to expand on this. It obviously hasn't been used for decades in D programs if you're proposing it as a new language feature. I don't remember ever using it in any language.
>>
>> It's been used as ref function parameters and foreach ref parameters, as mentioned in the DIP.
> 
> Then you're missing the very important qualification that they've been used successfully in other contexts. That doesn't provide evidence relevant to this proposal.

? The DIP says they've been used in other contexts. I don't see how this is not relevant.