The "@safe vs struct destructor" dilemma

[Nick Sabalausky]

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- at 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.