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 
make all non-extern (D) code implicitly @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?
Until DIP1028, putting @trusted: at the start of a module has 
always been considered bad practice and rightfully forbidden in 
libraries with a higher quality bar, such as phobos. But at least 
doing so is honest: you as an author are admitting that you don't 
have time to take care of @safe-ty for now, but it is likely ok 
to assume that the rest of your project is safe (well at least 
the @safe functions) *modulo* the @trusted parts. That way, later 
you can come back and search for @trusted and address those 
issues one by one.

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?
1. We accept a modified version of DIP1028 in which 
safe-by-default applies only to function definitions and 
extern(D) function declarations.
2. We add a separate compiler switch that changes non-extern (D) 
function declarations to be @trusted.
If you enable 1. and 2. you get the current version of DIP1028, 
but at least corrected, so that extern(C) code @trusted, and not 
@safe.
If you like this "feature" (2.) you're free to use it on your 
personal projects, but please don't force it on everyone who 
wants @safe to be something meaningful.