Allocator-aware @safe reference counting is still not possible

[Paul Backus]

On Monday, 23 January 2023 at 17:33:11 UTC, Dukc wrote:
>
> 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 @system code is not callable from @safe, 
but @trusted is. You can be as wrong as you want in @system code, 
and it will not compromise @safe code unless someone uses 
@trusted improperly.

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

In Richard Cattermole's hypothetical, the @trusted (or 
@localsafe) attribute is in the implementation of the container; 
for example:

     struct Vector
     {
         RCAllocator allocator;
         void[] memory;

         // ...

         ~this()
         {
             // ...
             () @trusted { allocator.deallocate(memory); }();
         }
     }

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

This would technically work, but I do not think I could look 
someone in the eye who was new to D and explain it without dying 
of embarrassment.