Allocator-aware @safe reference counting is still not possible

[Paul Backus]

On Monday, 30 January 2023 at 17:01:38 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 31/01/2023 5:27 AM, Paul Backus wrote:
>> I don't understand why you keep bringing this up--it's totally 
>> beside the point. Obviously most users should not need to use 
>> the allocator API directly.
>
> In the above case, with @system you could pass in whatever 
> pointer you want or extract the pointer out and lose any 
> protection that the given struct could provide. If the struct 
> is done simply, you could do this with @safe easily as well :/ 
> So not really appropriate for an allocator to return.
>
> So you remain in audit only territory of it.

We can use DIP 1035's @system variables to ensure that the 
wrapper struct's internals are not meddled with.

>> However, if you are *implementing* a data structure like a 
>> dynamic array, and you want to support user-supplied custom 
>> allocators, then the only way your data structure can be @safe 
>> is if the allocator API uses this kind of wrapper type to 
>> present a @safe interface.
>
> No?
>
> The data structure is the one doing the lifetime management. It 
> takes over from the language to keep the guarantees in check.

It seems as though you have completely failed to grasp the 
essential point of my original post [1].

In order for a data structure to provide these guarantees to its 
users, the allocator must, in turn, provide certain guarantees 
*to the data structure*. And if the data structure does not know 
in advance which allocator it will be using (e.g., if it is 
calling a generic RCAllocator.deallocate function), then those 
guarantees must be *encoded in the type system* somehow, so that 
@safe code cannot accidentally break them.

[1] 
https://forum.dlang.org/post/jsuraddtynhjoaikqprs@forum.dlang.org