Do we really need @unsafe?

[Don]

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