misplaced @trust?

[Steven Schveighoffer via Digitalmars-d]

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