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

[Jonathan M Davis]

On Wednesday, March 25, 2020 12:04:33 PM MDT Steven Schveighoffer via 
Digitalmars-d wrote:
> On 3/25/20 1:34 PM, bachmeier wrote:
> > On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:
> >> Everything else in the DIP is possibly annoying to deal with but at
> >> least doesn't silently destroy the meaning of @safe.
> >
> > To be perfectly honest, I can't imagine D being a sensible option for
> > someone wanting to work heavily with C code if you have to add pointless
> > annotations and constantly deal with compiler errors. It's not a matter
> > of annoyance, it's simply impractical to add that kind of overhead,
> > particularly if someone else is involved. If you're using C, you're well
> > aware that it's not going to be safe. Rust was designed for *writing*
> > safe code, not for wrapping C libraries, which is maybe the main use of
> > D right now.
>
> This is overblown. Adding @system: at the top of a c library header is
> not hard.
>
> Tools which generate headers for C libraries (e.g. dpp) can
> automatically do the right thing.

Not only that, but if _any_ function is automatically marked as @safe when
the compiler can't verify that it is, and no programmer has verified that it
is and marked it with @trusted, then @safe is borderline pointless and
useless, because it's not actually guaranteeing memory safety. We have
enough of a problem with programmers incorrectly using @trusted without the
compiler doing it. @safe needs to provide actual compiler guarantees, or it
just provides a false sense of security. extern(C) functions ultimately
exist in the call stack of every D program (even if most of them are buried
in D code rather than being used directly by the program), and to have those
treated as @system with no verification basically throws @safe's guarantees
out the window.

I agree with Walter's assertion that the DIP applies to extern(C) functions
unless it says otherwise, but that being the case, the DIP needs to be fixed
so that it does not apply to extern(C) functions, or it will do _far_ more
damage than good.

- Jonathan M Davis