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