DIP1028 - Rationale for accepting as is

[Petar]

On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote:
> [..]
> Yes, there's a cost, which is carefully vetting extern(C) and 
> extern(C++) declarations. The decision came down to finding 
> this an acceptable trade-off.

How would you feel about a DIP that the only thing it did was 
assume all non-extern (D) code was implciti @trusted? And how 
about if all such code suddenly became @safe without any vetting 
by developers and not even a compiler switch to revert to the old 
behavior?

As evidenced by the community outrage, no one but Walter and 
(maybe) you are convinced that safe-by-default on function bodies 
should imply @safe on non-extern(D) function declarations.

So how about a compromise? We accept a modified version of 
DIP1028 in which safe-by-default applies only to function 
definitions and extern(D) function declarations. And then there's 
a separate compiler switch that changes non-extern (D) function 
declarations to be @trusted? If you like this "feature" you're 
free to use it on your personal projects, but please don't force 
it on everyone who wants @safe to mean anything meaningful.