Discussion Thread: DIP 1028--Make @safe the Default--Final Review
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Mon Apr 6 18:45:14 UTC 2020
On Monday, 6 April 2020 at 12:35:20 UTC, Steven Schveighoffer
wrote:
> Is this really your argument? Do we need Scott Meyers to
> explain such "esoteric" compiler errors like:
>
> Error: cannot call @system function memcpy from @safe function
> main.
>
> I think this is not an hour-long talk, but a 10-second talk: "C
> functions aren't checked by the D compiler, so they are @system
> by default." Done.
We can do this even in the compiler. Since `@safe` checks cannot
be performed on a bodyless function, it should be an error to
declare a bodyless `extern(C)` function without either `@trusted`
or `@system` attribute explicitly marked.
And it should be straightforward to report this error, something
like:
Error: default @safe checks cannot be performed on extern
function `{name}`.
Please indicate explicitly whether this function is @system
or @trusted.
Honestly, I think we'd be far more in need of a Scott Meyers to
explain extern C functions being treated as safe by default (and
how to avoid unintended bugs caused by this) than by the
straightforward fact (well accepted e.g. by Rust users) that
extern functions cannot be assumed safe, because, well, how do
you prove it?
More information about the Digitalmars-d
mailing list