Type state analysis

[Atila Neves]

On Monday, 8 April 2024 at 20:10:24 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 09/04/2024 6:18 AM, Atila Neves wrote:
>> On Sunday, 17 March 2024 at 15:35:40 UTC, Paul Backus wrote:
>>> On Sunday, 17 March 2024 at 06:51:23 UTC, Richard (Rikki) 
>>> Andrew Cattermole wrote:
>>>> [...]
>>>
>>> Yet another proposal for a humongous language feature to 
>>> solve a problem that can already be solved without it.
>>>
>>> It is possible to achieve temporal safety in D already with 
>>> `scope` (DIP 1000) and `@system` variables (DIP 1035). The 
>>> ergonomics are not great, but they can be improved (e.g., 
>>> with built-in move-on-last-use).
>>>
>>> This proposal specifically has the same problem as `@live`: 
>>> it splits `@safe` code into separate "new `@safe`" and "old 
>>> `@safe`" dialects, which are mutually incompatible.
>>>
>>> The ideas themselves are not terrible. I would be interested 
>>> to see what this looks like implemented in a research 
>>> language. But I do not think it has any place in D.
>> 
>> I second all of the above.
>
> Just so we are clear, DIP1000 is not able to provide memory 
> safety on a single thread, let alone multiple.
>
> It is missing the child/parent relationship to prevent:
>
> ```d
> Parent* parent;
> Field* child = &parent.field;
> parent.destroy;
> Field value = *child;
> ```

DIP1000 depends on lifetimes and RAII, and in a language like D 
with constructors and destructors I struggle to find a reason to 
write `parent.destroy`. This works as intended, in the sense that 
it fails to compile:

```
     Field* child;
     {
         Parent parent;
         child = &parent.field;
     }
     Field value = *child;
```

It's the same reason why I don't understand "Logic errors such as 
trying to read from an unopened file" - why would a file be 
unopened?