DIP1028 - Rationale for accepting as is

[Petar]

On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
>> [..]
>> But with the DIP in its current form, we make @safe lose its 
>> meaning and power, which is much worse in my opinion.
>> [..]
>
> The alternative, not making extern @safe, would result in more 
> untrustworthy @trusted code we have to worry about. It's a 
> vicious circle.

Wrong. The quantity of untrustworthy code remains the same, but 
with DIP1028 (at least in the current form) the compiler sweeps 
the previously @system code under the rug and makes it harder for 
those who care about safety to trust @safe.

@safe must mean only one thing: compiler verified. Or otherwise 
needing less manual review. @system and @trusted means that code 
review should be prioritized. @safe non-extern (D) marked either 
by the programmer, or the implicitly by the compiler should be 
disallowed as it *is* greenwashing.

> I try to relax my view on extern annotations. They are @system. 
> We *should* go ahead and diligently mark with @trusted. From 
> experience, it doesn't normally happen.

It didn't happen, because it didn't need to. Naturally, most 
things go through the path of least resistance. Most developers 
are coming from other languages where they have never had the 
requirement to write @safe code [external pressure]. Also 
previously, @safe wasn't the default for D function definitions, 
so there was less [internal pressure] to do so. With @safe being 
the default of function definitions, it's more difficult to leave 
code as @system (of course, modulo @trusted).

> I don't like @safe extern, but it seems like the lesser evil.

No, @safe extern is the worst possible option! It basically makes 
@safe meaningless.

> Walter got a lot of flak. I tried to retrace his thoughts and 
> see the merits.

On several occasions (e.g. on Reddit) I have defended Walter from 
unfair accusations, however, in this case, he's rightfully 
criticized.
He seems to think that he's taking an unpopular decision for the 
greater good, but that's not the case. @safe-by-default on D 
function definitions could be considered an unpopular decision 
for the greater good. Implicitly @safe non-extern(D) functions is 
greenwashing, where the responsibility for the action is removed 
from the developer by a compiler switch. That's basically 
negating all the benefits of @safe-by-default on function 
definitions.