DIP1028 - Rationale for accepting as is

[Arafel]

On 27/5/20 11:50, Walter Bright wrote:
> 
> It is a fair point. But I am looking a bit farther than that - the team 
> that is responsible for QAing software (sometimes it is a separate 
> team). The QA team cannot tell the difference between correctly 
> annotated @trusted code and greenwashed code.
> 

This is a most unsubstantiated assertion.

If this were the case, I would have to wonder what the QA team is there 
for, if they can just be replaced by an automatic lint tool.

*AND* even if that were so, see below:

> But they can tell when code is not annotated (no, it is not harder to 
> do, the annotations are designed to not be hidden - annotations cannot 
> be hidden by the preprocessor nor are they propagated from imports. They 
> have to be there, and if grep doesn't find them, they are not there. 
> I've never had any difficulty finding the annotations belonging to a 
> declaration).
> 

Then the coder just slaps `@safe:`, `@trusted:`, or whatever 
greenwashing you were trying to avoid, and we're just back to square one 
since, per your previous assertion, QA can't notice the difference.

Heck, in such an environment I might slap `@trusted:` just in case at 
the beginning of each and every file and live in a land of bliss thereafter!

> Un-annotated C declarations should be a red flag to any competent QA 
> team. Recognizing a false @trusted is a whole lot harder.
> 

Exactly, which is why they should be disallowed by the compiler. 
Considering them `@system` by default is a way to do it. Another 
(perhaps even better) already proposed one would be to actually consider 
them `@safe`, but disallow `@safe` declarations where the code can't be 
analyzed by the compiler (it would be debatable if the mangling should 
be enough or not).

> BTW, one good thing that has come out of this issue is people are 
> strongly in favor of what @safe does. That bodes well for DIP1000 and 
> the @live code, for a long time I seemed to be the only one who cared 
> about it.
> 

Being in favour of what @safe purports to do and in favour of what it 
actually does are two very different things. The whole selling point of 
@safe used to be "you're only responsible for `@trusted` code, now 
that's no longer true (or at least even less, if we account for the 
already existing holes).

The direction of travel is opposite to the announced destination.

> I also have no problem if the D style checker checked for un-annotated C 
> declarations. That's the kind of thing it's for.
> 

So, if you leave them for the style checker that means that you envision 
cases where this could be the desired behaviour, otherwise you should 
just let the compiler error.

What would these cases look like? Because I can't imagine any.