Rationale for accepting DIP 1028 as is

Timon Gehr timon.gehr at gmx.ch
Thu May 28 10:20:14 UTC 2020


On 28.05.20 10:50, Daniel Kozak wrote:
>> He seems to think
>> that weakening @safe is worth doing, because it will ultimately mean that
>> more code will be treated as @safe and mechnically checked by the compiler,
> And I believe he is right.
> 

No, it's a false dichotomy. Weakening @safe to allow more code to be 
@safe might have been sensible if there was no @trusted annotation. 
However, as things stand, @trusted is sufficient as a tool to introduce 
potentially wrong assumptions about memory safety, we don't need more, 
especially not implicit ones.

The reason why people are not using @safe is partly that it is not the 
default, but it is mostly that their library dependencies _including 
Phobos_ are not properly annotated. This needs actual work to fix.

If there is significant perceived value in performing @safety checks in 
@system code, we can add a new function attribute that causes 
non-transitive @safe checks but otherwise gets treated as @system. @safe 
does not have to take this role.


More information about the Digitalmars-d-announce mailing list