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

[Timon Gehr]

On 09.04.20 07:12, Steven Schveighoffer wrote:
> On 4/9/20 12:31 AM, Timon Gehr wrote:
>> On 08.04.20 22:47, Steven Schveighoffer wrote:
>>> I never said that @trusted is the same as @system.
>>
>> Nor did I claim you did.
> 
> You just said:
> 
> "If your opinion is truly that the following two code snippets are 
> equivalent"
> 
> and then presented two code snippets that showed the same function with 
> implementation tagged as @system or @trusted. I don't know how I'm 
> supposed to interpret your claim other than you think I believe they are 
> equivalent.
> ...

I showed two code snippets with the same runtime semantics and compiler 
diagnostics. This is precisely the condition you used to conclude that 
tagging extern(C) prototypes with @safe or @trusted is equivalent.

Of course I am not claiming that you think @safe and @trusted are the 
same. I understand that you realize that one can write code that differs 
only in whether an annotation is @safe or @trusted but will give 
different compiler diagnostics. You are clearly very familiar with the 
mechanics implemented in the compiler but apparently you are confused 
about the underlying modular verification concepts.

>> The snippets above differ only in who is to blame for the memory 
>> corruption. You claimed that's a non-essential detail, and that is not 
>> true, but I don't know how to make that point to you.
> 
> The snippets are different than what we are debating.

Not at all, but apparently I was wrong when I assumed you are aware of 
that fact, so I wonder why you agreed that this is a waste of time.

> We were not 
> talking about trusted code being called from safe code, rather system 
> code being incorrectly prototyped as @safe or @trusted. Whether you mark 
> it incorrectly @safe or incorrectly @trusted is non-essential.
> ...

Of course it is essential that if you write only @safe code you can't 
get memory safety wrong. It does not matter if the @safe annotation is 
implicit or explicit. If you took quick a step out of the current 
debate, would you really consider this statement controversial?

> In both cases, the person who wrote the prototype is to blame, as the 
> person who wrote the original code clearly meant it to be system, and 
> the person who wrote the prototype got it wrong.
> ...

You can't blame the programmer who wrote only @safe code. It's just not 
an option. @safe absolves that programmer from any responsibility for 
memory corruption. That's what @safe is for and how it is advertised.

@system means: It's your responsibility to call this correctly.
@trusted means: I am taking responsibility for memory safety.
@safe means: The language is taking responsibility for memory safety.

The checks in @safe code are just the concrete way the language 
implements that responsibility. The details of how this is done in 
practice can evolve over time, but that fundamental spec is what it is.

> We have 3 situations:
> 
> 1. The code is written as extern(C) in D, in which case, the exact 
> safety attribute should be repeated as the prototype.

No, in this case ideally you would just use the module system and don't 
write any separate prototypes.

> 2. The code is written in some other language, but is @safe based on an 
> examination either by spec or by actually proofreading the code. In 
> which case, the prototype could be @trusted.

Sure.

> 3. The code is written in some other language, and does not follow 
> safety rules of D (e.g. memcpy). It should be marked @system.
> ...

Sure.

> In no circumstances should extern(C) code that is written outside D 
> should be marked @safe.

The compiler can not check that and has to assume the worst.

> I would also consider it an error to write a 
> prototype for an extern(C) D function other than what it actually is 
> (@safe, @trusted, @system).
> ...

So first you say there is no difference between @safe and @trusted on 
prototypes, and now suddenly it is wrong to interchange the two anyway.

> I consider both of those an error on the prototype author.
> 
> I would consider it a mistake to make it impossible to forward the exact 
> attribute of a @safe extern(C) D function to the prototype.
> 
> -Steve

As I said before, typeof(&foo) where foo is @trusted should be @safe. 
The difference is only important for the implementation/prototype, not 
the caller.