Allocator-aware @safe reference counting is still not possible

Dukc ajieskola at gmail.com
Tue Jan 24 14:51:06 UTC 2023


On Monday, 23 January 2023 at 17:44:03 UTC, Paul Backus wrote:
>> 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.

Now when I think of it, it probably should be called an allocator 
certificate and used for all allocators. `@trusted` required only 
if any of the other allocation primitives are `@system`. We have 
no reason to support allocators which might corrupt memory if 
they free their own memory after all, so no reason to name the 
certificate after reference counting.

Anyway, what's the problem? Perhaps we can improve this solution 
somehow. I agree with you that we do not want to wait for any 
major language-level changes, considering how long it took for 
DIP1000 to become stable.


More information about the Digitalmars-d mailing list