DIP1028 - Rationale for accepting as is

[Johannes Loher]

Am 27.05.20 um 11:50 schrieb Walter Bright:
> 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.

This is a very specific situation. There are a lot of teams / developers
that do not work in this manner. I don't know the numbers so I will make
no statement about what is more common but my personal experience is a
different one.

Also what is the difference between your QA department telling you to
correctly annotate C declarations and the compiler telling you that? If
you expect people to ignore what the compiler is telling them, why do
you expect them to listen to the QA department? In my opinion, the
compiler actually _is_ one of the best QA departments.

Also in my opinion, a competent QA department should carefully look at
any @trusted code /declarations. Maybe it is not a "red flag" but it is
definitely something that needs to be checked with extra care.