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

[Jonathan M Davis]

On Wednesday, March 25, 2020 9:36:15 PM MDT bachmeier via Digitalmars-d 
wrote:
> Let me put it differently. Suppose I release a linear algebra
> library that's a wrapper over a C library. Nobody using D the way
> it's supposed to be used can use my library. It just doesn't make
> sense for a language that claims strong C interoperability.
>
> Anyway, I'm going to let this die, because nobody else sees it as
> an issue.

In general, a D wrapper library around a C library should be presenting an
@safe API which was verified by the programmer who wrote that wrapper
library to be @safe. In some cases, that isn't possible, but regardless of
whether @safe and @system is actually a thing, code which can't present an
@safe API is a potential memory safety problem. D just makes it possible for
the compiler to flag stuff that it knows is not memory safe so that you can
easily find it and fix it. And the code that actually needs to do stuff that
the compiler can't guarantee is memory safe (and thus requires that the
programmer verify it) is then segregated by @trusted code so that you only
have to examine a relatively small portion of a library or program for
potential memory safety bugs.

D code does make it much easier to integrate with C code than is the case
with many other languages, but it also loses a lot of its value if the
compiler treats C code as if it were @safe even though its memory safety was
not verified by the compiler, and the programmer gave no indication to the
compiler that they had verified it. Having the compiler treat C bindings as
@safe by default would be a huge whole in @safe and make it much harder to
track down bugs related to memory safety when they occur.

- Jonathan M Davis