DIP 1028---Make @safe the Default---Community Review Round 1

Timon Gehr timon.gehr at gmx.ch
Thu Jan 9 19:22:28 UTC 2020

On 09.01.20 20:00, Steven Schveighoffer wrote:
> On 1/9/20 1:47 PM, Johannes Pfau wrote:
>> So by modifying @safe code only, you introduced a memory safety issue.
> Yes, this is why a function with ANY trusted blocks must be examined 
> completely, and changes to the non-trusted parts must be checked to see 
> if they cause problems with the trusted blocks.
> HOWEVER, it is still of tremendous value to have the rest of it 
> mechanically checked. So I still prefer this usage to trusting the whole 
> function.

If your @trusted code relies on @safe code to maintain safety-critical 
invariants, your @trusted code is broken. Any reasonable formalization 
of @trusted would declare such an usage invalid, so lowering the scope 
of @trusted to small blocks is not per se desirable.

@safe code can't be trusted. It may be edited by programmers who are not 
allowed to write @trusted code.

More information about the Digitalmars-d mailing list