On 4/12/2014 4:57 AM, deadalnix wrote:
On Friday, 11 April 2014 at 06:29:39 UTC, Nick Sabalausky wrote:
Realistically, I would imagine this @trusted part should *always* be a
dummy wrapper over a specific @system function. Why? Because @trusted
disables ALL of @safe's extra safety checks. Therefore, restricting
usage of @trusted to ONLY be dummy wrappers over the specific parts
which MUST be @system will minimize the amount of collateral code
that must loose all of @safe's special safety checks.
No.
Trusted is about providing a safe interface to some unsafe internals.
For instance, free cannot be safe. But a function can do malloc and free
in a safe manner. That function can thus be tagged @trusted .
The problem with that is @trusted also disables all the SafeD checks for
the *rest* of the code in your function, too.
To illustrate, suppose you have this function:
void doStuff() {
...stuff...
malloc()
...stuff...
free()
...stuff...
}
Because of malloc/free, this function obviously can't be @safe
(malloc/free are, of course, just examples here; they could be any
@system functions).
Problem is, that means for *everything* else in doStuff, *all* of the
...stuff... parts, you CANNOT enable the extra safety checks that @safe
provides. The use of one @system func poisons the rest of doStuff's
implementation (non-transitively) into being non-checkable via SafeD.
However, if you implement doStuff like this:
// Here I'm explicitly acknowledging that malloc/free are non-@safe
@trusted auto trustedWrapperMalloc(...) {...}
@trusted auto trustedWrapperFree(...) {...}
void doStuff() {
...stuff...
trustedWrapperMalloc()
...stuff...
trustedWrapperFree()
...stuff...
}
*Now* doStuff can be marked @safe and enjoy all the special checks that
@safe provides.
