Type state analysis

[Atila Neves]

On Wednesday, 10 April 2024 at 19:23:17 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
>
> 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.

Unless I'm missing something, that's exactly what DIP1000 does? 
How else would "order of invalidation" work except through 
scopes? Explicit destruction? Why do that??

>> 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),

What would an example of that look like?

> explicit closing

Doctor, doctor, it hurts when...

>, events handled automatically by OS.

Example?

> A lot of reasons.

I haven't encountered any; I'm not saying they don't exist, I'm 
saying that in my experience they're rare enough that they're 
approximately zero. I don't think that's ever happened since I 
stopped writing C. If one creates a file, it's open. If the file 
is no longer in scope, it's closed.