On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
@safe: the compiler checks
The compiler does not and cannot check inside @trusted.
Whether or not one requires extern(C[++]) to be behind or
within @trusted does not change what the compiler can or
cannot check.
Completely agree but my above says nothing about @trusted.
But it matters. Even if your code is @safe, that doesn't mean it
is completely safe. Your @safe code can call into somebody else's
@safe code that can call @trusted code that calls @system code.
If you want to guarantee that your code is safe, you'll have to
find and audit the @trusted bits (as well as everything that is
called from there).
If extern(C) is implicitly @system, you'll have to make calls
@trusted and they are subject to auditing. If extern(C) is
implicitly @safe, calls are still subject to auditing. Whatever
your preference, I think the compiler can be of greater help in
finding the bits that require auditing than grep can, and then
the difference isn't all that important anymore. Safe wrappers
around C libraries are still written the same way, audited the
same way, and unsafe calls into C caught the same way.
I agree that making extern(!D) @system looks sound, like the way
it should be. But it breaks compilation of existing code, and it
is too easy to evade by slapping on an explicit @trusted or (God
forbid) @safe. Or we could make extern(!D) to be anything other
than @system an error, which would be really annoying. I think
that what we all strive for is to reduce the strain of coding as
well as to reduce the strain of auditing.
-- Bastiaan.
