DIP1028 - Rationale for accepting as is

[WebFreak001]

On Wednesday, 27 May 2020 at 10:07:48 UTC, Johannes Loher wrote:
> Am 27.05.20 um 11:50 schrieb Walter Bright:
>> [...]
>> 
>> Un-annotated C declarations should be a red flag to any 
>> competent QA team. Recognizing a false @trusted is a whole lot 
>> harder.
>
> [...]
>
> 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.

I think additionally we shouldn't make D code review harder to do 
than it needs to be.

For a reviewer "something correct which is missing" is harder to 
pick up than "something wrong which is there" (@trusted/@system 
attributes)

When I, as an incompetent but trying QA department, come across a 
code change introducing a new module wrapping a C library and all 
tests pass, I would most likely not notice that the author did 
not type `@system:`. If there was an `@trusted:` at the top of 
the file it would be picked up by D-Scanner and help in code 
review. And well if someone slapped `@safe:` at the top of the 
file... read on:

Someone in this thread wrote something like "@safe" should be 
forbidden on functions without method body and instead only use 
@trusted or @system. I think it might even be you who brought it 
up? I love the idea of forbidding @safe when the compiler can't 
actually check the content of a function. @safe, @trusted and 
@system could then have perfect definitions without edge cases. 
And you would change the mangling of @safe and @trusted to be the 
same which was also brought up in this thread.