DIP 1028---Make @safe the Default---Community Review Round 1
schveiguy at gmail.com
Thu Jan 9 19:35:36 UTC 2020
On 1/9/20 2:22 PM, Timon Gehr wrote:
> 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.
I'm not saying it's safe. I'm saying I want the mechanical checking
outside the trusted escape. e.g. I want the compiler to check these
parts, but I know this one part needs trusting. D doesn't give a better
way to express this other than safe code with trusted escapes.
If I could mark the whole thing trusted, and turn on the mechanical
checking for everything except line X, then I'd do that instead.
More information about the Digitalmars-d