DIP1028 - Rationale for accepting as is

[Johannes T]

On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
> [..]

Thank you very much for your patience with all the negative 
feedback. I get your decision to not annotate extern C with 
@system by default. The biggest issue with extern @system is that 
@trusted would become less useful when dealing with declarations 
and bindings. @trusted would appear more frequently. We wouldn't 
be able to assume that the author put in effort in assessing the 
trustworthiness of a declaration. More greenwashing, less safety. 
Those are severe drawbacks, I agree.
However, as Andrei pointed out, PR is a huge problem. We need to 
be able to sell it with a straight face.
I think this might be done by formally redefining the meaning of 
safety attributes when applied to extern:
The safety of extern can't be assessed by the compiler. Implicit 
"@safe" extern within @safe code is accepted for the convenience 
of the average user. Explicit @system or @trusted can be added 
for desired behavior.
I think this can be explained.
It's not an acceptable solution for people who require 
correctness. ZombineDev can't tell an auditor that he relies on 
D-Scanner to find the problematic spots. I believe it's 
unavoidable to provide an option to change the default. It could 
make extern @system or refuse to compile safe code calling @safe 
extern.