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

[Bruce Carneal]

On Tuesday, 14 April 2020 at 18:54:29 UTC, Joseph Rushton 
Wakeling wrote:
> On Sunday, 12 April 2020 at 11:49:34 UTC, Jonathan M Davis 
> wrote:
>> If this DIP goes through as-is, we will be stuck explaining to 
>> D programmers for years to come why they have to be wary of 
>> the compiler treating extern(C) function declarations 
>> incorrectly and introducing invisible memory safety bugs into 
>> your program if you're not very careful. The compiler will 
>> actively be making dealing with extern(C) harder and more 
>> error-prone - and require more explanation to programmers 
>> learning D. On the other hand, if non-extern(D) declarations 
>> are @system by default or require explicit @safety attributes, 
>> then it's _simple_ to explain to people that that means that 
>> they need to be verifying the bindings for @safety and use 
>> @trusted appropriately - or that they need to just mark it 
>> them with @system and leave it up to whoever is using them. 
>> The only memory bugs introduced at that point will be because 
>> @trusted was used incorrectly rather than because an extern(C) 
>> declaration was incorrectly treated as @safe, because the 
>> programmer missed it.
>
> I really want to strongly back Jonathan here.
>
> I don't usually like to pull the "as a corporate user..." line, 
> but ... as a corporate user of D, it really matters to me that 
> `@safe` means that memory safety checks have actually been 
> performed on the code concerned, rather than just assumed.
>
> All things considered it seems to me like perhaps the most 
> straightforward way to avoid a horrible clash of concerns here 
> is just to insist that `extern` functions must always have an 
> _explicit_ (not inferred) memory safety attribute.
>
> That doesn't ban putting `@safe` on them explicitly -- which 
> might be something that could result e.g. from a `.di` file for 
> a D lib implementing `extern(C)` code -- but it would mean that 
> if `@safe` is on an extern function signature, it's because 
> someone deliberately put it there.

The further we get from @safe meaning "a vetted compiler checked 
this during this compilation" the less we should trust @safety.  
@safe via name mangling is, to me, just slightly less trustworthy 
than whole program compilation.  A .di file is less trustworthy 
as it's more likely to have been human edited.  An explicit @safe 
attribute on an extern C/C++ declaration is even less 
trustworthy, I'd treat it like an @trusted.

As bad as those are, the DIP would be significantly worse.  
Defaulting extern C/C++ to @safe means that you'd be on the hook 
for an @trusted style audit against the transitive closure of any 
such routines that you pull in.  Very few people are going to do 
that.