On Tuesday, 26 May 2020 at 18:06:00 UTC, Bastiaan Veelo wrote:
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).
Agree that the transitive closure is difficult, especially for
humans.
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.
Agree. @trusted doesn't mean that the code so labelled should be
blindly trusted. The aim should be reduction of @trusted where
practical. Silently letting all extern C functions inside the
tent is not a reduction.
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.
I'm all for reducing the strain of writing correct code.
As others have implied, we're dealing with, at least, two issues
here: 1) any transition from opt-in to opt-out safety will break
code. Some programmers will resort to greenwashing in an effort
to "fix" it. Will we be better off post transition? And 2)
should uncheckable code be considered @safe, ever.
