The "@safe vs struct destructor" dilemma

[deadalnix]

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 .

When you tag something @trusted, you are telling that the part 
aren't individually proven to be safe, but the develloper ensured 
that the whole, as seen from outside, is safe.

The thin wrapper thing do not really fit that model.

> If there really *isn't* a reasonable way to wrap @system struct 
> destructors (ex: RefCounted) inside an @trusted wall, then any 
> such structs will poison all functions which touch them into 
> being @trusted, thus destroying the @safe safety checks for the 
> *entire* body of such functions. Well, that is, aside from any 
> portions of the function which don't touch the struct *and* can 
> be factored out into separate @safe helper functions - but that 
> solution seems both limited and contortion-prone.
>
> Any thoughts?

RefCounted can't be made safe in any way given the current type 
system.