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

[Timon Gehr]

On 07.04.20 23:14, Steven Schveighoffer wrote:
> 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.

I guess I used the wrong word. What I meant was that there is zero 
checking that the extern(C) function you are calling was actually 
checked to be @safe. For extern(D), the language at least makes a small 
effort to ensure the @safe qualifier has some meaning, but given that 
return types are not mangled, that also seems like a lie.

> Even without intention. Having it 
> marked @trusted isn't any better than having it marked @safe in that case.
> ...

Memory corruption in a @safe context should be traceable to @trusted 
code. It's the entire point.

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

To show it's broken.

Besides that, it's not currently the default, and if it is, you might 
want to temporarily switch to @system and back. In any case, @safe code 
by definition is code written by untrusted programmers. Why do you 
insist there should be a good reason? Maybe the programmer was a monkey. 
Or malicious.

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

Because the extern(C) function can be changed to be @system. Hence you 
must trust the maintainer of the prototype to keep it in sync with the 
implementation.

> How does that prevent problems?

The point is to be able to trace any problems to some @trusted 
annotations. @safe alone doesn't completely prevent memory safety 
problems, but it advertises giving you a way to completely avoid being 
blamed for them. (Except for your choice of programming language, I 
suppose.)

> It's functionally equivalent.

$ grep @trusted *.d

Also, if you had in fact successfully identified a case where @safe and 
@trusted are functionally equivalent, why would that not ring alarm 
bells? If you write @safe, you don't actually mean @trusted.

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

I really don't understand why anyone would argue in favor of a policy 
that allows code to become less safe when you annotate it @safe.

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

They were not incorrect, and the bad reasoning about those cases was 
caused by a lack of understanding of formal logic and type theory. This 
is also the underlying cause for the inout-related type system holes.