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

[Jonathan M Davis]

On Wednesday, March 25, 2020 1:03:16 AM MDT Mike Parker via Digitalmars-d 
wrote:
> This is the feedback thread for the Final Review of DIP 1028,
> "Make @safe the Default".

The line "Interfaces to extern C and C++ functions should always be
explicitly marked" is pretty vague from the perspective of a spec. Does it
mean that the compiler will require that the programmer mark extern(C)
functions as @system, @trusted, or @safe and that extern(C) functions
without any of those attributes are illegal? Or does it have a default if
not provided, and it's just that it's best practice for the programmer to
explicitly specify it? And if it has a default, what is the default?

Based on the paragraph above stating that "An unmarked extern (D) function
will now be considered @safe," I would guess that that means that any
functions which aren't extern(D) (be they extern(C), extern(C++),
extern(ObjC) or whatever) would be treated as @system if not marked
otherwise (just like happens now), but I think that the DIP should be
explicit about it.

There's also the question of declaration vs definition for functions which
aren't extern(D). It makes no sense for a function declaration which is not
extern(D) to be treated as @safe by default, because the compiler can't
guarantee its @safety. However, I don't think that it would be a problem for
non-extern(D) function definitions, because then the compiler _can_ check
their @safety. Either way, the DIP should be explicit about what happens
with declarations and definitions which are not extern(D) - regardless of
whether declarations and definitions are treated differently.

I'd also argue that @safe should not be allowed on function declarations
which are not extern(D), because the compiler can't guarantee their @safety
(meaning that if an explicit @safety attribute is supplied, it must either
be @system or @trusted), and allowing @safe on non-extern(D) declarations
makes it much harder for programmers to grep for @trusted code that could be
the source of @safety problems. In practice, right now, I'm unaware of
anyone marking extern(C) declarations as @safe, but if someone did, it could
be very hard to track down the problem if it were hiding a memory safety
bug, and given the ease of marking all declarations and definitions in a
module with @safe via @safe: or @safe {}, it wouldn't surprise me if some
code bases are accidentally marking extern(C) declarations with @safe right
now and thus hiding memory safety issues. However, allowing @safe on
non-extern(D) function _definitions_ should be fine, since then the compiler
actually is verifying the code. Regardless, much as I think that the DIP
_should_ make it illegal to mark non-extern(D) declarations as @safe, that
would arguably be an improvement over what the DIP currently does rather
than being required for the DIP to actually make sense or be acceptable.

- Jonathan M Davis