"Dmitry Olshansky" wrote in message news:ltv91u$2mtc$1...@digitalmars.com...
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.
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.
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.
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.
