DIP1028 - Rationale for accepting as is
Johannes Loher
johannes.loher at fg4f.de
Mon May 25 10:19:22 UTC 2020
On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote:
> 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.
So basically you are saying we should do it the way it is
described in the DIP because otherwise it will lead developers to
incorrect usage of @trusted (just slapping it on declarations
whiteout actually checking the implementation) thus making it
loose its „power“ which leads to less safe code.
But with the DIP in its current form, we make @safe lose its
meaning and power, which is much worse in my opinion. It makes
the statement „@safe code cannot create memory corruptions except
for @trusted code“ wrong (it already is wrong now but it really
shouldn’t be!).
What you are describing is really just an admit of defeat. Then
why still bother with @safe at all if it doesn't give us any
meaningful guarantees? I don't think we are at that point (yet).
More information about the Digitalmars-d-announce
mailing list