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