Allocator-aware @safe reference counting is still not possible

[Richard (Rikki) Andrew Cattermole]

On 24/01/2023 5:39 AM, Paul Backus wrote:
> On Monday, 23 January 2023 at 08:49:50 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Basically right now we're missing the lifetime checks surrounding 
>> borrowed & function parameter. Everything else is do-able right now, 
>> even if it isn't as cheap as it could be (like RC eliding).
> 
> 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.

> 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.