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

[Steven Schveighoffer]

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.

-Steve