Rationale for accepting DIP 1028 as is

[Paul Backus]

On Tuesday, 26 May 2020 at 17:50:58 UTC, Gregory wrote:
> Which will just lead people to pure @trusted: at the top of 
> their code to get it to compile again, with or without 
> extern(C) being @safe by default. Then someone that uses it as 
> dependency will mistaken think it is @safe. What's to stop this 
> kind of "greenwashing" and why is greenwashing only important 
> to prevent when talking about extern(C) but every other code 
> that will break from this change?

The reason extern function declarations are particularly 
problematic is that changing them from @system-by-default to 
@safe-by-default can cause *silent* breakage in existing, correct 
code. By "silent", I mean that there is no message from the 
compiler warning you that the memory safety of the code has been 
compromised. It will still compile, and you will only find out 
that something has gone wrong when you run into memory corruption 
at run-time.

This undermines the entire purpose of @safe, which is to 
automatically catch code with potential memory errors at compile 
time.