On 2/9/2015 6:21 PM, H. S. Teoh via Digitalmars-d wrote:
What stops the following abuse of @trusted via
trusted()?
int* myFunc(void* p) @safe // <-- I'm claiming to be @safe
{
// But actually I'm not! Though I can convince the
// compiler that I am...
return trusted!(() => cast(int*)p);
}
char c;
auto p = myFunc(&c); // oops
*p = 999; // kaboom
Are we just relying on convention that trusted() will not be abused in
this way?
That's right. @trusted will always rely on convention.
And how would we prevent users from defining similar templates for
escaping safety without being readily detectable, e.g., by grepping for
'trusted'?
auto sneaky(alias fun)() @trusted { return fun(); }
Or is this a case of "if you insist on shooting your own foot the
compiler can't/won't help you"?
The very idea of @trusted is you're trusting the programmer with something that
cannot be mechanically checked.
RULE 4: Escape unsafety must not inject unsafety beyond the template
function it is used in.
IOW, the following is illegal?
int* myTemplate(void* p) @trusted // <-- illegal leakage of unsafety
{
return trusted!(() => cast(int*) p);
}
Depends on the usage context, i.e. "beyond the template function it is used in".
2. isSafe!T template
Such a template would test that all operations on type T are @safe.
The template function could then be marked @trusted. The troubles with
this are (a) it is all or nothing with T, i.e. if a template function
only used an @safe subset of T, it still would not be accepted and (b)
it does not do proper inference of the safety of a template function.
What about isSafe!(T, method1, method2, ...)? I.e., test the safety of
an explicit list of operations that the template function will be using?
Listing the operations to be used is the same as the if(0) solution.
