Allocator-aware @safe reference counting is still not possible

[Paul Backus]

On Monday, 30 January 2023 at 18:59:38 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> I'm not expressing myself clearly enough but the goal posts I'm 
> recommending are the same as at the start. Check as much as 
> possible with @safe, but let data structures be responsible for 
> as much of the life time guarantees wrt. allocators as possible.
>
[...]
> I'm half and half. Stuff like @localsafe would mean that I 
> think that allocators should all be @system in API. I'm 
> genuinely reconsidering it for my own because of this thread.
>
> But in terms of hard coding into the compiler std.allocators vs 
> sidero.base.allocators yeah no. It shouldn't do that, which is 
> what the quoted statement was about. If both API's match, then 
> the compiler should treat them the same way in terms of 
> lifetime management.

So, what, we should allow @safe data structures to call @system 
allocators and simply *assume* that the allocator implementation 
won't do anything weird? And if someone writes their own 
allocator implementation, and doesn't manually check that their 
@system code provides the guarantees that the data structures 
expect, we're ok with them getting memory corruption in @safe 
code?

To me this seems antithetical to the entire idea of @safe. It's 
what Walter calls "programming by convention," where the only 
thing standing between the user and disaster is programmer 
discipline. I do not think he or Atila would be willing to accept 
it (nor would I accept it in their place).