DIP1028 - Rationale for accepting as is

[Walter Bright]

On 5/27/2020 3:07 AM, Johannes Loher wrote:
> 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.

I've seen larger companies operate this way. Smaller ones cannot afford to.


> 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?

The QA dept is motivated to not be taken in by greenwashing.

(Back in my days at Boeing, I worked in the design department. There was an 
entirely separate organization call the Stress Group. Their job was to sign off 
on every nitpicky detail. If they signed off on something that turned out to be 
wrong, it was bad for their careers. Your designs did not move forward without 
Stress signoff. If you tried to trick Stress, that was the end of your career at 
Boeing.)

So yeah, there's a huge difference between tricking the compiler and tricking 
the QA department.


> In my opinion, the
> compiler actually _is_ one of the best QA departments.

Indeed it is, and that's the whole point to @safe. My motivation here is make 
suspicious code stand out. @trusted code does not stand out so much, because it 
is required to exist.


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

Looking at un-annotated declarations should be the first step. If it is 
annotated with @trusted, at least there's the coffee stain on the drawing 
indicating that somebody looked at it.