DIP1028 - Rationale for accepting as is
Johannes T
isrvoid at gmail.com
Mon May 25 09:25:52 UTC 2020
On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
> [..]
After thinking about it, Walter ultimately made the right
decision, leading to overall higher safety and code quality.
We all agree that making extern C @safe is incorrect. It's also
meaningless. Even if you were to verify the safety of a specific
version of your binding, it can't be known what's loaded at
runtime. It's not the compiler's concern. @safe extern shall be
an error. We might additionally make an exception and make all
extern C @system. It would be correct for the declarations, but
inconsistent in regard to default safety. It doesn't affect the
outcome. Let's say we'll go with @system, it gives us a bit more
freedom.
We hit compile, our now safe wrappers are errors. We are most
likely to do one of two things, depending on the module failing
to compile. If it mostly wrappers, we slap @trusted: at the top.
If there are just a few functions calling C, we only annotate
those with @trusted. Let's be real, we probably won't begin
checking and annotating the trustworthiness of the C functions.
An individual programmer might, but not on average.
We are formally correct, but @trusted can't be trusted at this
point. It has lost its meaning. We now have to check all foreign
@trusted code, which we probably won't.
We could have moved the problem one level down and slapped
@trusted: on top of the @system declarations. Now there is a
bunch of safe code using them. It doesn't change much. @trusted:
is easier to grep, but we won't put everything down and begin
trustworthily annotate extern C. So yeah, I do believe Walter was
right. @safe on extern is formally incorrect but leads to safer
code because @trusted still has its power.
More information about the Digitalmars-d-announce
mailing list