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