Allocator-aware @safe reference counting is still not possible

[Paul Backus]

On Monday, 23 January 2023 at 16:59:16 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 24/01/2023 5:39 AM, Paul Backus wrote:
>> Have you seen the borrow method [1] used by SafeRefCounted? It 
>> is already possible, in the current D language, to prevent a 
>> container or smart pointer from leaking references. The syntax 
>> is awkward, because you have to use a callback, but it can be 
>> done.
>
> Yes I'm aware of this method. I've talked about it with Robert 
> Schadek during last DConf Online who argued that this is the 
> only way forward. This is not the way forward as far as I'm 
> concerned. It is a major step backwards in usability as it is 
> not how people work with arrays or data types in general.

I agree that it's bad UX, but what's the alternative? Implement a 
borrow checker in D? It'll take 5-10 years and won't even work 
properly when it's done. At that point, you may as well just tell 
people to switch to Rust.

>> Lifetime issues are not the blocker here. The blocker is being 
>> able to give deallocate/free a safe interface, so that it can 
>> be used safely in a generic or polymorphic context, where the 
>> specific implementation is not known in advance.
>
> I can't agree with that. We need to move people away from 
> calling into allocators directly! They are an advanced concept, 
> that is easy to get wrong especially when creating them. Which 
> is what composing them like std.experimental.allocators does.
>
> Ultimately, I think its ok for allocators to not be @safe, they 
> are simply too easy to get wrong without any way to prevent 
> this at the compiler level. You use them when you want to do 
> something more advanced without any hand holding. Use data 
> structures like a vector type to make it @safe instead, which 
> is why I think lifetime is the only thing blocking it atm.

I am not advocating for typical D users to call into allocators 
directly. The people who benefit from allocators having a @safe 
interface are authors of generic container and smart pointer 
libraries.

It is currently *impossible* to write a @safe vector type that 
accepts a user-supplied allocator. You can only do it if you 
hard-code a dependency on a specific allocator (or a specific 
predefined set of allocators) whose behavior you know in advance.

If your argument is that we should do exactly that, and simply 
give up on supporting user-supplied allocators entirely, then I 
can accept that as a reasonable position. Certainly it would be 
the quickest and easiest way to un-block progress on containers, 
and we can always revisit the issue in the future if necessary.