DIP1028 - Rationale for accepting as is

[jmh530]

On Friday, 22 May 2020 at 16:03:00 UTC, Steven Schveighoffer 
wrote:
> [snip]
>

Fortunately, the above point can be more easily fixed by making 
`free` @system, which will then require annotating every 
subsequent piece of code that touches it. It's annoying 
transition, but it's do-able. The problem is when you aren't sure 
what needs to be marked @system. For instance, if you have some 
function now that is @system by default and does pointer 
arithmetic, then the switch to @safe by default will result in 
that no longer compiling. That's good. The emphasis on prototypes 
is that the compiler will not be able to notify you that the 
function should not be compiled. If the `free` function comes 
from a prototype (and thus cannot be manually verified by the 
compiler), then that is much worse for safety than a `free` 
function with the full body available.

This comes back to a point I had made on one of the original DIP 
discussion threads that one issue is that @safe is a blacklist of 
things you can't do rather than a whitelist of allowed things. If 
@safe were designed as a whitelist, then only things that are 
compiled verified could be marked @safe. That means that a 
function without a body should not be inferred to be @safe.

That `static if` thing just looks like a nightmare, but I think 
the point still applies that you will get error messages if the 
body is available and you try to do something that isn't @safe.