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.