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

[Jonathan M Davis]

On Thursday, March 26, 2020 10:02:22 AM MDT Atila Neves via Digitalmars-d 
wrote:
> On Thursday, 26 March 2020 at 11:40:41 UTC, IGotD- wrote:
> > FFI functions like extern(C) must be @system as the compiler
> > cannot check this. Should extern(C) automatically mean @system?
> > Well I think so because that's the only feasible possibility.
>
> The problem I see is this:
>
> extern(C) int add1(int i, int j) @safe {
>      return i + j + 1;
> }
>
> extern(C) doesn't necessarily mean the code is written in C and
> can't be verified by the compiler. It might just be written in D
> (or C++, or Rust, or...). I do however understand why one would
> want to say that an external C library has no @safe interface.
> But that can be done by applying @system manually. I'm not sure
> what the best solution is.

The issue is that the compiler should never treat anything as @safe unless
it has verified that it's @safe, or the programmer has explicitly marked it
as @trusted. Anything else introduces holes into the @safety system.

So, it should be fine to treat any and all function definitions as @safe by
default, because the compiler can verify their @safety and provide the
appropriate errors when the code isn't actually @safe. However, any function
_declarations_ which are not extern(D) must not be treated as anything other
than @system by default, or they introduce a hole into the @safety system.
If the compiler treats them as @safe by default, then it's essentially
marking them as @trusted for the programmer. They haven't been verified by
the compiler, and they haven't been verified by the programmer. So, they
silently introduce code that is potentially memory unsafe into your program.
It then becomes impossible to find all memory safety issues by looking for
@trusted code, and it becomes trivial to accidentally use a function which
really isn't @safe without realizing it, because the compiler implicitly
marked its declaration as @safe even though it wasn't verified for @safety.

extern(D) function declarations are of course fine, because the name
mangling ensures that their definitions have actually been verified for
@safety if they're marked as @safe, but the same is not true for any other
function declarations.

Either all non-extern(D) function declarations should be treated as @system
unless otherwise marked (as is currently the case), or they should require
that the programmer explicitly mark them as @system or @trusted. Simply
treating them as @system by default would of course be the simplest, and I
don't really see a problem with that.

But no, it's not simply a question of extern(C) vs extern(D), because that's
just a matter of linkage and name mangling. It's non-extern(D) function
declarations specifically which are the problem. As long as the DIP only
makes @safe the default for function definitions and extern(D) function
declarations, then it should be fine, but it currently isn't very clear on
the matter. It clearly indicates that extern(D) functions will be treated
@safe by default, but it uses vague language about what's supposed to happen
with non-extern(D) functions, and it makes no mention of function
declaration vs definition.

- Jonathan M Davis