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

[Steven Schveighoffer]

On 4/6/20 2:28 PM, Timon Gehr wrote:
> On 06.04.20 01:38, Steven Schveighoffer wrote:
>> 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.

The linker can always hijack it. Even without intention. Having it 
marked @trusted isn't any better than having it marked @safe in that case.

> 
>> Assuming @safe, no. Explicitly @safe OK, you marked it, you own it.
>> ...
> 
> @safe:
> 
> // a lot of code
> // ...
> 
> extern(C) corrupt_all_the_memory();

Why would you do this when @safe is the default?

> 
> 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.

If you mark a @safe extern(C) function @trusted, how does that help? I'm 
talking about extern(C) functions that are checked by the compiler as 
@safe. Why should I have to mark the prototype of that function 
@trusted? How does that prevent problems? It's functionally equivalent. 
It's not something that changes when the original extern(C) function for 
some reason becomes @system (unlike extern(D) code).

I agree with the concept that it's impossible for the compiler to know 
that an extern(C) prototype is @safe, but I think it's more bureaucratic 
than effective to make you use @trusted instead of @safe. It's like a 
law that has roots in good policy, but results in a lot of frivolous 
enforcement.

>> 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.

No, they were obvious. If you have an inout return but no inout 
variables, the "what goes in comes out" doesn't make any sense. Just use 
const in that case.

But it turns out it's just easier for generic code to have these cases 
devolve into the equivalents that just use const/immutable, so you don't 
have to use static if's everywhere.

> I think you can just grep for the error messages and then remove the 
> checks.

I think there are more things than that. For example, inside non-inout 
code, you need to figure out what inout means, and enforce that.

-Steve