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

[Steven Schveighoffer]

On 4/8/20 4:04 PM, Timon Gehr wrote:
> 
> I'll explain why I think it's the case: If your opinion is truly that 
> the following two code snippets are equivalent, we have reached an 
> irreducible position:
> 
> ---
> void corrupt_memory()@trusted{ ... }
> 
> void main()@safe{
>      corrupt_memory();
> }
> ---
> ---
> void corrupt_memory()@system{ ... }
> 
> void main()@system{
>      corrupt_memory();
> }
> ---
> 
> Anyone who thinks those two code snippets are essentially the same can 
> safely ignore my line of argumentation, but everyone else should dismiss 
> yours.

Strawman.

I never said that @trusted is the same as @system. I said that a @system 
function which has a @safe prototype is identical to a @system function 
that has a @trusted prototype. In both cases, the compiler accepts the 
function as callable from @safe code, does no checking, and never alerts 
the user.

The only reasonable case where extern(C) code that is actually @system 
should be prototyped @trusted is when the code isn't written in D. In 
that case, it's not possible to mark it @trusted, but one can reasonably 
assume that the code is technically @safe. For instance libc's cos() or 
something similar.

extern(C) code that is not checked @safe SHOULD NEVER be prototyped 
@safe. But it makes no sense to prevent extern(C) code that is @safe 
from being prototyped as @safe. Requiring one to write @trusted doesn't 
change anything as the code is still callable via @safe code, and just 
creates unnecessary annoyances.

We should not prevent accurate prototypes just because it's possible to 
write them incorrectly. Especially when the prevention doesn't disallow 
the exact same inaccurate prototypes written with @trusted vs. @safe.

If requiring @trusted prototypes for @safe functions gained any 
measurable quantity of safety, it would be worth it. It doesn't, so it's 
not.

-Steve