Encapsulating trust

[Daniel Murphy via Digitalmars-d]

"Dmitry Olshansky"  wrote in message news:lu4kgh$mpm$1 at digitalmars.com...

> Probably a lot of people missed the point that if we standardize a few 
> idioms (dangerous but at least centralized) we at least can conveniently 
> contain the "abuse" of @trusted to the select standard module. Else it 
> *will* be abused in a multitude of ways anyway.

> we at least can conveniently contain the "abuse" of @trusted to the select 
> standard module

This is Wrong!  Any function that uses these wrappers is abusing @trusted.

eg:

import stdx.trusted;

int* func(int x) @safe
{
    return addrOf(x);
}

This functions is @safe, but happily returns an invalid pointer.  This is 
possible because addrOf violates the requirement that @trusted functions 
must be completely @safe to call from an @safe function.

Say we have a very useful function like this:

void doThing(bool corruptRandomMemory) @system { ... }

So if the parameter is true, it will cause memory corruption, otherwise it 
will not do anything that violates @safe.

This is a valid @trusted wrapper:

void doThingTrusted() @trusted { doThing(false); }

This is not:

void doThingTrusted(bool b) @trusted { doThing(b); }

Having syntax (or a wrapper function) to do the second wrapping 
automatically would violate @safe.  If it was syntax, it would be banned in 
@safe.  If it's a wrapping method like the proposed 'call', then it is a 
program error for it to be marked @trusted.