Type state analysis

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Mon Apr 8 20:10:24 UTC 2024


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;
```

This happens to be one of the things that the DFA is capable of 
tracking, that is not currently possible to implement (Dennis has tried).

It also does not  provide any way of tracking memory from creation to 
ensure it can be transferred safely to another thread in its entirety to 
prevent needing things like locks.


More information about the dip.ideas mailing list