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