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