On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves 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.j
Completely agree but my above says nothing about @trusted.
@safe post 1028: the compiler checks, sometimes, just not in
the scary parts
The amount of code that requires human auditing remains the
same. What matters is how to find that code, and how to
maintain the validity of the audits.
Another distinction: pre 1028 your compilation will error out.
Post 1028 it will not.
Quite the opposite. Most code out there isn't marked as
@safe/@trusted/@system. If I add a dub dependency and don't
bother with @safe, I can call anything, in any way. Post
1028... nope. Unmarked @system function definitions themselves
won't compile.
Which will just lead people to pure @trusted: at the top of their
code to get it to compile again, with or without extern(C) being
@safe by default. Then someone that uses it as dependency will
mistaken think it is @safe. What's to stop this kind of
"greenwashing" and why is greenwashing only important to prevent
when talking about extern(C) but every other code that will break
from this change?
