Direction for @safe/-dip1000

[deadalnix]

On Monday, 14 February 2022 at 22:46:09 UTC, Paul Backus wrote:
> On Monday, 14 February 2022 at 21:14:08 UTC, Elronnd wrote:
>> On Monday, 14 February 2022 at 21:02:31 UTC, Timon Gehr wrote:
>>> @live is only useful in @trusted or @system code as a linting 
>>> tool.
>>
>> Devil's advocate: @nogc.
>
> @live does not help at all with writing @safe @nogc code.
>
> In order for @safe or @trusted code to rely on @live's 
> ownership invariants (e.g., "a non-scope pointer owns the 
> memory it points to"), it must be impossible for @safe code to 
> violate those invariants. Since @live's invariants are only 
> enforced in @live functions, and @safe code is allowed to call 
> non- at live functions, it follows that @safe code is allowed to 
> violate @live's invariants, and therefore that those invariants 
> cannot be relied upon by @safe or @trusted code.
>
> To fix this, you would have to introduce new rules such as
>
> * All @safe functions must also be @live
> * @safe functions cannot call non- at live functions
>
> Of course, adding rules like this would break literally every 
> @safe function in every existing D project, so it is totally 
> infeasible in practice--and that's why the current design for 
> @live is a dead-end.

This is 100% correct.

In addition, taking a step back, it is abundantly clear that 
slapping an attribute on any problem that comes up only create a 
combinatorial explosion in the language that is fundamentally 
unsustainable.

In the end, because these tend to contradict, the language cannot 
provide any guarantee one can rely on.