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

[Steven Schveighoffer]

On 4/5/20 3:57 PM, tsbockman wrote:
> On Sunday, 5 April 2020 at 19:22:59 UTC, Timon Gehr wrote:
>> That makes no sense at all. You are arguing in favor of _ at trusted_ by 
>> default! It should not even be _possible_ to mark an extern(C) 
>> function @safe, it has to be either @system or @trusted. The compiler 
>> does not do any checking here.
> 
> I agree completely with this: it should be a compile-time error to 
> declare a bodyless extern(C) function @safe, regardless of whether it is 
> done implicitly by default, or explicitly with an annotation.
> 
> The only distinction between @safe and @trusted is the compiler 
> verification of the safety of a function's implementation. If that 
> compiler verification wasn't done, then @safe cannot rightly apply.
> 
> If having a different implicit default for bodyless extern(C) functions 
> is too complicated, then just don't have a default for them at all: 
> require all such declarations to be explicitly annotated either @system 
> or @trusted.

I disagree with disallowing @safe as a specific marking on extern(C) 
code. You can write @safe extern(C) functions in D, and it makes no 
sense to require that they are @trusted at the prototype. Assuming 
@safe, no. Explicitly @safe OK, you marked it, you own it.

We have similar problems with inout -- preventing obvious incorrect 
cases makes sense, until it doesn't. I wish now I could go back and 
change what I thought, but unfortunately I'm not well-versed in the 
compiler to make the changes myself.

-Steve