Allocator-aware @safe reference counting is still not possible

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Mon Jan 30 18:59:38 UTC 2023


On 31/01/2023 7:49 AM, Paul Backus wrote:
> On Monday, 30 January 2023 at 18:33:57 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> If we hired some people then yes 1&2 (but not 3). Otherwise we are 
>> stuck with changing the goal posts from perfect to good enough for the 
>> time being. As Andrei use to say: perfect is the enemy of the good; 
>> which is unfortunately what I think we need to strongly consider here. 
>> We have what appears to be a pretty decent path forward for 'good'.
> 
> I'm not opposed to the idea of moving the goalposts in principle, I am 
> just not sure where you are proposing that we move them to. :) It seems 
> like every time I ask, I get a different answer.

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.

Perfect solution: all code is mechanically checked.

Good solution: library and under the hood code gets audited, user code 
of the library code gets mechanically checked.

Let's have a good solution, then try to figure out if we can remove 
restrictions and get a perfect solution in the library code as well.

>> It shouldn't matter what allocator library you use. Either it works or 
>> it doesn't. The compiler shouldn't care whose code it is, only the 
>> lifetime patterns.
> 
> For example: I agree with this paragraph in principle, but isn't this 
> one of the goalposts that you were just saying we should be willing to 
> move?

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.


More information about the Digitalmars-d mailing list