I think there is an exit to the current impasse that has been
overlooked thus far.
The key question is, during a safety audit, how to find the
unsafe sections of code that need to be vetted thoroughly. If DIP
1028 is kept as is, these sections can be found by `grep
@trusted|extern\(C`. If DIP 1028 would be amended as many argue
for, it would be `grep @trusted`. But isn't grep a rather crude
tool, and wouldn't the compiler be able to create more useful
reports either way?
The compiler already has options for listing gc allocations
(-vgc) and variables that go into thread local storage (-vtls). A
new option could be implemented to list all @trusted functions
and all calls into extern(C[++]) functions from within safe
sections.
It is the calls into extern(C[++]) functions that cannot be
guaranteed to be safe, irrespective of whether the declarations
are marked @trusted or @safe. So listing these calls is much more
valuable than grepping for @trusted, which can be misused as
"@trusted extern(...". If a C library has a proper D wrapper that
defines a safe interface, only the @trusted functions in the
wrapper would appear in the list, not the extern(C) calls that
are made within its @trusted functions. The list could possibly
be reduced by excluding functions that are never called, making
it even more valuable.
@trusted is not a seal of approval. It bears no signature, nor a
hash of the implementation. It is simply a bridge from safe
territory into unsafe territory, and is a checkpoint that cannot
be skipped in any certification process.
Considering this, the compiler can actually produce a hash of the
implementation of trusted functions as part of this list. A
certification authority can then actually use this list to
maintain a table of sections, hashes and stamps. If a new release
needs to renew its certification, the earlier table can be
compared against the current list, and functions whose hash
didn't change need not be reviewed again. Extrapolating even
further, this could be the basis of a repository of approvals
from various individuals and authorities representing statements
like "I have looked at this function carefully and I believe it
can indeed be trusted".
I think this would be a tool that adds real practical value and
helps to reduce the cost of audits. And not the least, regarding
the current discussion, it diminishes the importance of whether
extern(C[++]) declarations are actually @system or @safe.
-- Bastiaan.
