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

Arafel er.krali at gmail.com
Sun Apr 5 09:50:58 UTC 2020


On 5/4/20 11:12, Walter Bright wrote:
> On 4/4/2020 1:09 AM, Jonathan M Davis wrote:
>> Anything else would go against what @safe is supposed to be promising.
> 
> Extern declarations are the USER making promises. Even with extern (D), 
> the return type isn't mangled into the name. The User has to get it right.

I'm not a heavy user or a big contributor of D, but just my 2¢: I find 
this totally unexpected. To me as a non-guru it breaks the principle of 
least astonishment and I'm convinced it will just generate confusion and 
subtle bugs.

Of course the user can always explicitly mark functions as @system, but 
then I bet that more than 99% of the external declarations (without 
function body) will have to be tagged as such. Since Walter has always 
defended sane defaults, I think this is one prime case to apply this 
principle.

In fact, a new user who is not that adept at D and its subtleties, and 
that just wants to interact with a C library would find very surprising 
that his expected @safe code is no longer @safe *without even a warning*.

Even more, marking declarations without body as @system wouldn't even be 
an exception to any rule. The way I understand the different safety 
levels is the following (please correct me if wrong):

@safe: Memory safety has been proven and enforced by the compiler 
according to a know set of rules.
@trusted: Memory safety has been manually proven / promised by the user.
@system: Everything else.

If we follow this, marking *any* functions without body by default as 
@system would be the logical thing to do, because they haven't been 
proven neither by the compiler nor (by default, one would assume) by the 
user. Furthermore, it shouldn't be possible for such a function to ever 
be @safe, at most it should be @trusted.

In fact, assuming @safe would break the promise above!

The only exception would be then where the mangling already indicates 
this, as in "extern (D)". Since the mangling is already trusted, it 
would be no exception in this case.

Of course, there's the argument that the user should know that he has to 
do the verification for each function, and that by just putting the 
declaration there he is implicitly taking responsibility for the memory 
safety of the function, and that it's up to him to mark it as @system if 
needed.

But then, wouldn't that be an argument to assume everywhere @trusted by 
default? If the user is responsible for marking non-trusted function 
declarations, why not do the same for non-trusted function definitions?

Just assume that all function bodies are safe, and ask the user to slap 
@system on those who aren't!

Isn't that an inconsistency as well?

A.


More information about the Digitalmars-d mailing list