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