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

[Arine]

On Thursday, 9 April 2020 at 05:12:41 UTC, Steven Schveighoffer 
wrote:
> We have 3 situations:
>
> 1. The code is written as extern(C) in D, in which case, the 
> exact safety attribute should be repeated as the prototype.

I don't think that should be the case. If the code is writen in D 
you should just import and use it. Otherwise all extern(C) should 
either be @trusted or @system. The extern(C) is a source for user 
error and the types aren't checked through mangling. So the 
@trusted would indicate that declaration needs to be checked. 
Even if the body of the function is in D and the function is 
defined as @safe. Since C mangling doesn't incorporate types or 
@safety, if you do define it as @safe in another module, then the 
implementation changes, it will still link to the function even 
if it becomes @trusted.

I think this is where the whole @system/@trusted/@system system 
starts to fall flat on its face, along with other situations. If 
you think of this as either unsafe or safe, then it is a lot 
easier. A extern(C) declaration without body would always be 
unsafe, it would be unsafe by default and there's no "safe" 
keyword (ala rust) to make it safe. Something that needs to 
default to unsafe, should stay unsafe. If there's a body of the 
function it would would be safe as you can verify the 
implementation. If you import that module, it has all that 
information available and it knows the declaration is correct, 
what types and such it uses. If you declare extern(C) elsewhere 
then that's the possibility for error that the declaration goes 
out of sync of the implementation, and C's mangling won't save 
you. It *needs* to be verified by an individual.