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.
