Allocator-aware @safe reference counting is still not possible

[Dukc]

On Monday, 23 January 2023 at 16:33:11 UTC, Paul Backus wrote:
> The problem is that, in a generic allocator-aware container, if 
> you write a @trusted/@localsafe call to RCAllocator.deallocate, 
> there is nothing to stop someone from writing a custom 
> allocator with a deallocate function like this:
>
> struct NaughtyAllocator
> {
>     // ...
>
>     @system void deallocate(void[] block)
>     {
>          corruptMemory();
>     }
> }
>
> ...and then RCAllocator.deallocate will dispatch to this 
> function, and you will end up corrupting memory in @safe code.

Yes... but note that this does require writing `@system` code 
wrong. In that sense it's no different from someone providing
```D
@trusted void naughtyFunction() => corruptMemory();
```

The difference is that in the allocator there's no user-provided 
`@trusted` attribute you can point to and say "this one has the 
problem".

We could require that any allocator that's supposed to be safe 
for reference counting must have a member function `@trusted 
@disable void refCountCertificate();`, with `@trusted` attribute 
being checked for. That way it's not possible to corrupt memory 
in `@safe` code without writing at least one `@trusted` function.