DIP1028 - Rationale for accepting as is

[Walter Bright]

On 5/26/2020 12:18 AM, Johannes Loher wrote:
> Just think about what the developer's reaction would be in the situation I 
> described in my last post, when he actually finds the issue.
> 
> In your variant, the developer will be questioning why the compiler did not help 
> him at all with realizing that there might be a problem. It is very likely that 
> he blames the issue on the compiler.
> 
> In the other variant, he will realize that this something he had been warned 
> about by the compiler and that he made a careless wrong decision and that it is 
> his own fault. In the future he will be likely more careful when it comes to 
> annotating stuff with @trusted. So this even has an educational effect.

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.

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).

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

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.

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.