DIP1028 - Rationale for accepting as is

[Timon Gehr]

On 24.05.20 05:28, Walter Bright wrote:
> I'd like to emphasize:
> 

I understand all of those points and most of them are true, and obvious.

The issue is that they are not a justification for the decision. You 
seem to think that greenwashing is not greenwashing when it is done by 
the compiler without user interaction. Why is that?

> 1. It is not possible for the compiler to check any declarations where 
> the implementation is not available. Not in D, not in any language. 
> Declaring a declaration safe does not make it safe.
> ...

Which is exactly why it should not be possible to declare it @safe.

> 2. If un-annotated declarations cause a compile time error, it is highly 
> likely the programmer will resort to "greenwashing" - just slapping 
> @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've 
> all done it. Sometimes even for good reasons.
> ...

Slapping @safe on it should not even compile. You should slap either 
@system or @trusted on it.

> 3. Un-annotated declarations are easily detectable in a code review.
> ...

It's easier to find something that is there than something that is not 
there. Greenwashing is not easier to detect if the compiler did it 
implicitly.

> 4. Greenwashing is not easily detectable in a code review.
> ...

Even though it is easy to miss in a code review, it's easy to detect 
automatically. Any extern(C) prototype that is annotated @safe 
(explicitly or implicitly) is greenwashed.

> 5. Greenwashing doesn't fix anything. The code is not safer.

Actually further down you say that it makes the code safer in a 
"not-at-all obvious way". Which is it?

> It's an illusion, not a guarantee.
> ...

Yes. On the other hand, @trusted is not an illusion, it is a way to 
clarify responsibilities.

> 6. If someone cares to annotate declarations, it means he has at least 
> thought about it, because he doesn't need to.

True, but this is an argument against restrictive defaults in general, 
in particular @safe by default. Also note that if someone cares to 
annotate declarations, the compiler pointing out missing annotations 
that would otherwise cause implicit greenwashing is _useful_.

> Hence it's more likely to be correct than when greenwashed.
> ...

This is true whether or not the compiler does the greenwashing 
implicitly. Annotating with @safe is a lie, whether the compiler does it 
or the programmer. It should be rejected and force @system or @trusted. 
You can still quickly see a difference in applied care by checking 
whether it's a single @trusted: or each prototype is annotated individually.

> 7. D should *not* make it worthwhile for people to greenwash code.
> ...

Greenwashing automatically is not a solution, it's admitting defeat. Why 
can't the compiler just reject greenwashing with @safe?
Slapping @trusted on prototypes is not greenwashing, it's saying "I take 
responsibility for the memory safety of this external C code".

> It is, in a not-at-all obvious way, safer for C declarations to default 
> to being safe.

@safe is advertised to give mechanical guarantees, where @trusted is a 
way for programmers to take responsibility for parts of the code. It is 
not advertised to be an unsound linter with pseudo-pragmatic trade-offs 
and implicit false negatives.