01-Sep-2014 20:36, Daniel Murphy пишет:
"Dmitry Olshansky" wrote in message news:[email protected]...
Quite recently a lot of work has been done to make most of Phobos
usable in @safe code.
While a very welcome effort, it caused a number of doubts in
particular due to the boilerplate required to isolate a small amount
of unsafe operations and slap "@trusted" over it.
See e.g. Denis argument:
https://github.com/D-Programming-Language/phobos/pull/2465
There were proposals for language changes along the lines of having
@trusted block alike to debug/version blocks, but nothing ever came
out of them.
Without language support I decided it worth a shot to create a
universal wrappers to establish a consistent convention. A use of such
wrapper should indicate that a @system function call or language
feature was hand-verified.
What do you guys think?
I think this is an abuse of @trusted. It takes unsafe operations, and
re-presents them as @safe options by renaming them. Now, you can do use
@system things in @safe functions without the compiler detecting it.
Take the `addrOf` function for example. This is equivalent to adding a
new version of the '&' operation, which does exactly the same thing
except it's allowed in @safe code. The `addrOf` function should _not_
be @trusted, because when used from @safe code it can cause escape the
address of a local etc, just like '&' can.
Because these functions violate the meaning of @trusted, that @trusted
functions must be @safe although the compiler can't prove them @safe,
you've increased the surface of @trusted. Now an audit of @trusted code
must include all functions that call `addrOf` and friends.
Only these that import stdx.trusted. Trivial to check.
I don't think this is a good idea. Each time @trusted is used, it
should be on a function that is completely @safe to call. I think this
is worth more than the cost in verbosity.
I'd be damned but it's made precisely because taking address is
frequently needed in a function that is otherwise @safe. Alternative of
marking the whole thing as @trusted ain't going in the right direction.
Instead of writing the same ugly shit (pardon local functions and
lambda+call) everywhere, let just compose a set of markers (2-3
functions) that indicate something as trusted block.
Obviously one can easily abuse it, much like @trusted can be easily
abuse today, especially with templates where it's easy to fail in trap
of putting @trusted on the whole function and trust pretty much any 3rd
party type to be safe.
Lambdas and nested functions are special in that they can't be called
from other code, so they only have to be @safe in the context of the
enclosing function. They do still need to make sure they don't violate
@safe, otherwise the entire enclosing function will need to be manually
checked.
They have in common is lot of noise that distracts and obfuscates the
thing that already needs our full attention making it both bigger and
harder to follow.
eg
void fun(int a) @safe
{
...
p = @trusted () { return &a; }
...
}
This function is now essentially @trusted, because although the unsafe
'&' operation was inside the trusted block, the @safe function now has a
pointer it should not have been able to get.
Careful there - a trusted lambda must ensure that pointer is fine,
although the means of getting it are @system. The same review-driven
thing about @trusted remains.
--
Dmitry Olshansky
