Allocator-aware @safe reference counting is still not possible

[Paul Backus]

On Sunday, 25 September 2022 at 15:07:04 UTC, Dukc wrote:
> On Sunday, 25 September 2022 at 14:52:09 UTC, Paul Backus wrote:
>> Well, of course, if you are willing to write unsound 
>> `@trusted` code, anything can be made `@safe`. :)
>
> The `SafeRefCounted` destructor wouldn't be any less sound that 
> it's now. If `free` did something it's not supposed to, the 
> `@trusted` attribute on the destructor would be invalid. It 
> isn't any different with a custom deallocator.

`free`'s interface is defined by the C language standard. There 
are a lot of safeguards in place, both social and technical, to 
prevent a non-conformant implementation of `free` from making its 
way into your program. Therefore, it is not a big risk for 
`SafeRefCounted`'s `@trusted` destructor to rely on the behavior 
of `free` conforming to the C language standard.

No such safeguards exist to prevent users of a hypothetical 
allocator-aware `SafeRefCounted` from passing in a custom 
deallocator that violates safety when called from the same 
destructor. So the risk of allowing memory corruption in `@safe` 
code is much, much, higher when using a custom deallocator than 
it is when using `free`.