Allocator-aware @safe reference counting is still not possible

[Dukc]

On Sunday, 25 September 2022 at 12:03:08 UTC, Paul Backus wrote:
> This progress has in turn enabled the creation of 
> `SafeRefCounted` by Ate Eskola, which will hopefully be 
> available in the next release of Phobos.

Well Atila started it, so he has a bit of credit. I "stole" his 
PR at some point.

>
> The next logical step on this journey is a version of 
> `SafeRefCounted` with support for `std.experimental.allocator`. 
> Unfortunately, this step is where we run into a roadblock.
>
> `SafeRefCounted` is allowed make a `@trusted` call to `free` 
> when it knows it holds the only pointer to its payload, because 
> it knows (from the C standard) that `free` will not corrupt 
> memory when called under those circumstances.
>
> However, an allocator-aware version of `SafeRefCounted` that 
> calls a generic `Allocator.deallocate` function instead of free 
> specifically has *literally no idea* what that function will 
> do, and therefore cannot mark that call as `@trusted`, ever, 
> under any circumstances.

I think it can. We need to agree on what the deallocator can and 
cannot do. If the deallocator then does something disallowed, 
then its the deallocator that's to blame, not `SafeRefCounted`. 
The deallocator, unless it's an intentional memory leaker or the 
GC, cannot be `@safe` anyway, so there's no way for the user to 
cause UB without writing incorrect `@trusted` or `@system` code.

>
> The only solution is to somehow allow `deallocate` (and by 
> extension `free`) to have a `@safe` interface on its own—which 
> isn't possible in the current D language. At minimum, it would 
> require something like an [`isolated` qualifier][3] (h/t 
> deadalnix for the link), which would guarantee that a pointer 
> is the only pointer to a particular block of memory. Some form 
> of ownership/borrow checking would also work, of course.

I do concur that reading how `isolated` works is worth it for 
anyone thinking how to improve `@live`.