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

[sarn]

On Thursday, 26 March 2020 at 23:09:23 UTC, H. S. Teoh wrote:
> 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.
> [...]
>
> 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

I strongly agree with this viewpoint.  Calling extern(C) code is 
like anything else @safe prohibits.  Yes, it *could* be safe, but 
the compiler should flag if @safe code potentially calls code 
written in a language that isn't memory safe, and the onus should 
be on the programmer to check the code and mark it appropriately.