Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[jmh530]

On Saturday, 4 April 2020 at 16:44:48 UTC, Steven Schveighoffer 
wrote:
> [snip]

For all the discussion about @safe meaning that the compiler has 
verified that a function is @safe, that's not really what @safe 
does. @safe is a blacklist, preventing some operations in @safe 
functions, not a white list that only allows verifiable ones in 
@safe functions. Granted, I think a whitelist would have been a 
better idea if it was done from the start, but that's not really 
what we have and I'm not sure the current conversation 
appreciates that difference. @safe (currently) doesn't actually 
verify that everything is safe, rather it just says you can't do 
these unsafe things. Maybe extern(C) functions with no body 
should be added to the @safe blacklist? That would mean that if 
@safe is the default, then those functions won't compile. The 
user will need to use them through a @trusted interface. Now, I 
don't like that solution by itself, but at least it is consistent 
with how @safe is designed (as a blacklist).