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

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Mar 26 23:09:23 UTC 2020


On Thu, Mar 26, 2020 at 04:22:01PM -0600, Jonathan M Davis via Digitalmars-d wrote:
[...]
> So, it should be fine to treat any and all function definitions as
> @safe by default, because the compiler can verify their @safety and
> provide the appropriate errors when the code isn't actually @safe.
> However, any function _declarations_ which are not extern(D) must not
> be treated as anything other than @system by default, or they
> introduce a hole into the @safety system.
[...]

Very good, I think this is the key point here.  If a function is
*defined* (i.e., function body is visible to the compiler), then it
doesn't matter whether it's extern(C) or not, it can be @safe by default
because the compiler will check the function body and reject it if it
breaks @safe.

Where the problem crops up is when it's an extern(C) *declaration*
without a function body.  Then assuming @safe by default is essentially
equivalent to declaring @trusted: at the top of the file, because who
knows *what* that declaration will actually bind to at runtime.  You're
essentially blindly trusting that the C code (or D code, but the
compiler can't tell) behind it is actually @safe.  And worse than the
programmer writing @trusted: at the top of the file, this is *implicit*,
and the programmer may not even be aware that there's a problem.


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.


More information about the Digitalmars-d mailing list