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

[Steven Schveighoffer]

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.

> But still, it seems like applying trusted/safe at function level provides
> stronger guarantees. I wonder how other languages deal with that? Not at
> all and just be extra careful when writing trusted blocks?
> 

Yes, this is exactly correct. Trust must happen at the function level, 
because that's where you can reason about the parameters and returns. 
Marking it safe is not really because the function is safe, it's because 
marking the WHOLE function trusted is to forgo all checking inside the 
function, which is not what you normally want.

If we could design it again, probably you should have safe and system be 
what they are today, trusted would be safe, except where you put in 
unsafe blocks. This allows the code to pick which parts should be able 
to call system functions.

But I think this is digressing from the DIP discussion quite a bit. 
Probably best to continue if necessary in a new thread.

-Steve