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

[Joseph Rushton Wakeling]

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.