On 2/5/15 2:17 PM, H. S. Teoh via Digitalmars-d wrote:
I mostly like this idea, except that foo() should not be marked @safe. It should be marked @trusted because it still needs review, but the meaning of @trusted should be changed so that it still enforces @safe-ty, except that now @trusted variables are permitted. Or rather, I would call them @system variables -- they *cannot* be trusted, and must be manually verified.
I still am not sure I get this idea. If @safe code can call @trusted code, how is it any more mechanically verified than @trusted code?
API-wise, there is no difference. The whole idea of @trusted is that you don't need to go read the implementation, you have to trust the person writing it. As a user of @trusted function, I really don't care whether it's marked @safe or @trusted. And I shouldn't be able to break my @safe function by calling it.
@safe code should not allow any @system variables or any cast(@safe) operations, period. Otherwise, anybody can wrap unsafe operations inside their @safe function and still clothe it with the sheep's clothing of @safe, and @safe becomes a meaningless annotation.
The only way to fix this is to ban @trusted altogether. Which makes @safe quite useless indeed. -Steve
