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.
