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

[Timon Gehr]

On 06.04.20 01:38, Steven Schveighoffer wrote:
> 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.

The linker can hijack them. The function signature of a @trusted 
function should be @safe anyway.

> Assuming 
> @safe, no. Explicitly @safe OK, you marked it, you own it.
> ...

@safe:

// a lot of code
// ...

extern(C) corrupt_all_the_memory();

When did @safe become a matter of "it's your own fault if you shoot 
yourself in the foot, this memory corruption you are having is a good 
thing because it will teach you not to make more mistakes in the 
future"? If something may break @safe-ty as it trusts the programmer to 
get it right, it ought to be @trusted.


> We have similar problems with inout -- preventing obvious incorrect 
> cases makes sense, until it doesn't.

This is not analogous. Here, the problem is that the "obvious incorrect 
cases" where not actually incorrect.

> 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
I think you can just grep for the error messages and then remove the checks.