"Dmitry Olshansky" wrote in message news:lu4kgh$mpm$1...@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.
