Allocator-aware @safe reference counting is still not possible

Paul Backus snarwin at gmail.com
Mon Jan 30 21:01:34 UTC 2023


On Monday, 30 January 2023 at 19:34:05 UTC, Dukc wrote:
> On Monday, 30 January 2023 at 17:36:59 UTC, Paul Backus wrote:
>> As far as I am aware, it is impossible to have all three of 
>> the following:
>>
>> 1. @safe containers.
>> 2. User-supplied allocators.
>> 3. No language changes.
>
> Earlier I presented the idea to require a `@trusted` 
> "certificate" function from the allocator. You agreed that it 
> satisfies all of these in principle, but you wouldn't consider 
> it in practice because it'd be embarrassing to explain for an 
> outsider.
>
> Can you elaborate why? Maybe we can have some further ideas.

The fundamental problem with it is that there is no enforcement 
mechanism (other than convention) preventing an allocator from 
having a `@trusted` certificate and misbehaving anyway. In 
particular, anyone who works on the allocator after its initial 
implementation has to "just know" somehow (documentation? 
comments?) that changes to its `@system` functions must be 
reviewed for compliance with the `@trusted` certificate.

Requiring manual verification of `@system` code is something we 
are trying to move away from in D (see DIP 1035), and adopting 
this scheme would be a step backwards.


More information about the Digitalmars-d mailing list