DIP1028 - Rationale for accepting as is

[RazvanN]

On Wednesday, 27 May 2020 at 10:40:18 UTC, Walter Bright wrote:
> 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.
>
I'm utterly confused by this.

Trusted code is always suspicious and always stands out because 
it is not formally verified whereas @safe code should be 
bulletproof. Why would anyone bother to manually check code that 
is supposed to be @safe? Trusted code is the villain here; 
wherever you see @trusted you know that the code might contain 
vulnerabilities because it was audited by a human and not by a 
machine.

If you have @safe code that has memory safety issues (from 
callinc C functions) then what's the point of @safe?

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