Allocator-aware @safe reference counting is still not possible

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


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.

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

Ultimately, data structures and algorithms typically need auditing to 
make sure they are doing what they are supposed to be doing. I strongly 
believe adding a whole lifetime tracking feature in what should be 
library code won't have the ROI in adding it to the language.

On that note, Dennis has done some work to replace some scope inference 
which should offer the infrastructure required to plug the last big hole 
in lifetime tracking of borrowed memory from a data structure :) 
https://github.com/dlang/dmd/pull/14492


More information about the Digitalmars-d mailing list