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

[Jonathan M Davis]

On Sunday, April 5, 2020 3:12:21 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 4/4/2020 1:09 AM, Jonathan M Davis wrote:
> > Anything else would go against what @safe is supposed to be promising.
>
> Extern declarations are the USER making promises. Even with extern (D),
> the return type isn't mangled into the name. The User has to get it
> right.

Sure, the user has to get the declaration right, but @safe is about the
compiler verifying code for memory safety, and in the case of extern(C)
declarations, it has not done that. IMHO, it's not even appropriate for a
programmer to put @safe on an extern(C) declaration, and it should be
illegal, because the compiler didn't verify it. If the programmer verified
it, then they should be using @trusted. And this DIP will end up having the
compiler slap @safe on it even though it hasn't verified anything.

Right now, if a programmer doesn't mark an extern(C) declaration with
@system, it's still treated as @system (and thus unverified by either the
programmer or the compiler), and there are no @safety problems. When the
function is used in @safe code, the fact that declaration is @system will be
flagged as an error, and either the programmer will determine that it can be
@trusted (and thus explicitly mark it as @trusted), or the code using it
will have to do stuff in a way that _it_ can be @trusted. Either way, you
don't end up with code with memory safety bugs being treated as @safe unless
the programmer screws up with @trusted.

After this DIP, if the programmer screws up and forgets to mark an extern(C)
declaration as @system, the compiler will happily treat it as @safe even
though neither the programmer nor the compiler has verified it for memory
safety. And voila, the programmer's screw-up caused a bug in the code
instead of being caught by the compiler, whereas with the current behavior,
the compiler would catch it and force the programmer to verify the code for
@safety. With this DIP, the programmer can no longer rely on @safe code
being memory safe so long as @trusted was not incorrectly applied.

Arguably even worse, all of the existing extern(C) declarations out there
which currently are quite reasonably left unmarked and treated as @system
will suddenly be treated as @safe. Code which worked perfectly fine before
will break. This DIP effectively breaks _all_ existing non-extern(D)
declarations which have not explicitly been marked as @system or @trusted,
and it does so invisibly. To deal with this, every D library and program
will have to have be searched for declarations which are not extern(D) so
that they can be marked with @system - something that the compiler really
should be doing - and invariably, some of them will fall through the cracks
and introduce @safety bugs.

I really don't understand your position on this. It's so simple and
straightforward to just treat all declarations which are not extern(D) as
@system by default, and there's _no_ downside to it from the standpoint of
anyone who isn't a compiler dev. On the contrary, it maintains the default
that all non-extern(D) declarations should have, because they haven't
actually been verified by the compiler for memory safety, and it prevents
bugs. Making @safe the default for non-extern(D) declarations will just
introduce bugs rather than fix them. It solves nothing while being
error-prone and introduing a hole into @safe at the same time that we're
trying to improve it. From the standpoint of a programmer using the
language, there is literally _no_ upside to treating extern(C) declarations
as @safe by default. It just increases the odds that extern(C) declarations
will be wrong and introduce bugs.

@safe is supposed to mean that the compiler verified the function for memory
safety. @trusted is supposed to mean that the programmer verified it. And
@system is supposed to mean that it's unverified. _Please_ don't change
that.

- Jonathan M Davis