Walter Bright wrote:
@unsafe was suggested (I think by Don) to provide symmetry with @safe
and @trusted. This is a good point, but I'm starting to think that
@unsafe is not a good idea.
For example, one could make an entire module safe with:
-------------------
module foo;
@safe:
[...]
-------------------
And an observer could conclude that foo only contains safe and trusted
code. But if @unsafe could override, he has to delve into it looking for
@unsafe as well.
Furthermore, why would a safe module wish to expose unsafe functions?
Shouldn't the programmer instead be obliged to produce trusted functions
in it?
I'm thinking from a library developers viewpoint. Unsafe functions are
required to allow users to write their own trusted functions.
It's possible to make these functions private, but that's at the expense
of functionality.
If we don't have @unsafe, then an unlabelled function means the function
is either "not checked for safety" _or_ "known to be unsafe". Those are
two radically different things. Even if not using SafeD, marking
functions as unsafe is valuable documentation.
Actually, I'd hope for a way of checking that @unsafe functions are
called only from @trusted functions, and NOT from unmarked ones --
that's the way I'd proceed in moving a codebase over to 'safe'.
Based on the idea that the most common cause of safety violation is via
passing incorrect parameters. (contracts are based on the same idea).
