Type state analysis

[Richard (Rikki) Andrew Cattermole]

On 11/04/2024 7:17 AM, Atila Neves wrote:
> 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;
> ```

Yes, because of the explicit scope creation. The compiler can see it 
cross scopes, but not within a scope this requires tracking of values 
and their order of invalidation.

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

Accidental, different scope states (conditional/function calls), 
explicit closing, events handled automatically by OS.

A lot of reasons.