Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Jonathan M Davis]

On Sunday, April 5, 2020 5:38:21 PM MDT Steven Schveighoffer via 
Digitalmars-d wrote:
> On 4/5/20 3:57 PM, tsbockman wrote:
> > On Sunday, 5 April 2020 at 19:22:59 UTC, Timon Gehr wrote:
> >> That makes no sense at all. You are arguing in favor of _ at trusted_ by
> >> default! It should not even be _possible_ to mark an extern(C)
> >> function @safe, it has to be either @system or @trusted. The compiler
> >> does not do any checking here.
> >
> > I agree completely with this: it should be a compile-time error to
> > declare a bodyless extern(C) function @safe, regardless of whether it is
> > done implicitly by default, or explicitly with an annotation.
> >
> > The only distinction between @safe and @trusted is the compiler
> > verification of the safety of a function's implementation. If that
> > compiler verification wasn't done, then @safe cannot rightly apply.
> >
> > If having a different implicit default for bodyless extern(C) functions
> > is too complicated, then just don't have a default for them at all:
> > require all such declarations to be explicitly annotated either @system
> > or @trusted.
>
> I disagree with disallowing @safe as a specific marking on extern(C)
> code. You can write @safe extern(C) functions in D, and it makes no
> sense to require that they are @trusted at the prototype. Assuming
> @safe, no. Explicitly @safe OK, you marked it, you own it.
>
> We have similar problems with inout -- preventing obvious incorrect
> cases makes sense, until it doesn't. I wish now I could go back and
> change what I thought, but unfortunately I'm not well-versed in the
> compiler to make the changes myself.

Except that it _does_ make sense to mark it as @trusted, because the
information about the body having been verified by the compiler to be @safe
is lost due to the lack of extern(D) name mangling. The compiler has no way
of knowing whether the function was written in D and compiled by dmd
elsewhere or whether it was compiled as C code elsewhere. When you mark an
extern(C) declaration with anything other than @system, you're telling the
compiler that it's @safe, and @trusted is the appropriate attribute for the
programmer to be telling the compiler that a function is @safe, whereas
@safe is the approrpiate attribute for when the compiler does it on its own.

Allowing @safe on extern(C) declarations doesn't help at all over adding
@trusted on them, and it makes it easier for them to be accidentally treated
as @safe without the compiler verifying them if someone uses

@safe:

Also - and perhaps most importantly - if an extern(C) function must be
marked with @trusted or @system and cannot be marked with @safe, then when
there's a memory safety bug, you know that you only have to look for
@trusted code (and what it calls) to find the problem. Barring compiler
bugs, you can ignore all @safe code. However, if @safe is allowed on
non-extern(D) declarations, then you also have to go searching for all
non-extern(D) declarations to make sure that they were not incorrectly
marked with @safe. Being able to find code with memory safety bugs by
grepping for @trusted is supposed to be a key feature of the @safety system,
but it doesn't work if @safe is allowed on code that the compiler didn't
explicitly verify - and it has no way of knowing whether the body of an
extern(C) function was verified when all it sees is the declaration.

@safe should _only_ be used when the compiler is promising that it's
mechanically verified the code for @safety. @trusted is what should be used
if the programmer verified it, and in the case of extern(C) declarations,
it's always going to be the programmer that verifies it regardless of
whether the body itself was verified for @safety by the D compiler. To allow
@safe on extern(C) declarations just muddies what @safe means and makes it
harder to track down bugs.

If there were a way for the compiler to know that the extern(C) definition
had been verified for @safety, then the situation would be different, and it
would be reasonable to mark the declaration as @safe, but the compiler has
no way of knowing that, so @safe on extern(C) declarations is inappropriate
and should be illegal.

- Jonathan M Davis