Discussion Thread: DIP 1035-- at system Variables--Final Review

[Dukc]

On Tuesday, 22 February 2022 at 15:05:14 UTC, Nick Treleaven 
wrote:
> On Sunday, 20 February 2022 at 15:16:30 UTC, Dukc wrote:
>> Why we want to do that at all? DIP1000. Most of the potential 
>> of DIP1000 is wasted if you cannot prevent destruction before 
>> end of the scope:
>>
>> ```D
>> @safe void abuse()
>> { auto cont = SomeRaiiContainer([1,2,3]);
>>   scope ptr = &cont.front;
>>   destroy(cont);
>>   int oops = *ptr;
>> }
>> ```
>
> Doesn't the same problem occur just with reassignment?:
>
> ```d
>   scope ptr = &cont.front;
>   cont = cont.init;
>   int oops = *ptr;
> ```

Reassignment can be forbidden at least. But still, my point does 
not stand scrutiny, because:

1: No reassignment is clumsy.
2: Even accepting that, this would still do the same thing:
```D
   auto pCont = new SomeRaiiContainer([1,2,3]);
   scope ptr = &pCont.front();
   pCont = null;
   GC.collect;
   int oops = *ptr;
```

So, stratch that. RAII or reference counted containers can only 
be `@safe` with a callback based usage, as suggested by Paul: 
https://github.com/dlang/phobos/pull/8368#issuecomment-1024917439 
. And that idiom is `@safe` even with present destructors. 
Hopefully: We have discovered so many in our DIP1000-based memory 
safety schemes lately so there is no guarantee that this isn't 
still just some oversight.