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

[H. S. Teoh]

On Wed, Mar 25, 2020 at 01:37:53AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> Since @safe will now be the default, all extern functions will be
> @safe.
[...]

I strongly oppose this. Defaulting extern(C) functions to @safe does not
make sense if the declarations are for interfacing with a C library,
because we all know too well that C libraries tend to be full of pointer
bugs, buffer overflows, and security holes. C simply doesn't have the
mechanisms in place to ensure @safety, and the D compiler cannot check
the code at all.  *At best* extern(C) functions of this kind can only be
@trusted (and I would also oppose defaulting them to @trusted, because
that would be equivalent to blindly tacking @trusted on everything just
to get things to compile).

Blindly assuming extern(C) functions to be @safe, which is essentially
what defaulting extern(C) functions to @safe effectively does, is an
extremely bad idea, and is a prime example of a wrong default.

I support @safe by default for "extern(D)" functions, but I strongly
oppose @safe by default for extern(C) functions. They need to be
individually vetted before being marked @trusted.  I'd say they should
not be marked @safe unless they are actually written in D and can be
verified by the compiler.  And since there's no easy way to tell apart
which extern(C) functions are written in D and which are written in C,
we should conservatively assume @system unless explicitly marked @safe.


T

-- 
What do you call optometrist jokes? Vitreous humor.