Allocator-aware @safe reference counting is still not possible
Paul Backus
snarwin at gmail.com
Mon Jan 23 17:44:03 UTC 2023
On Monday, 23 January 2023 at 17:33:11 UTC, Dukc wrote:
>
> Yes... but note that this does require writing `@system` code
> wrong. In that sense it's no different from someone providing
> ```D
> @trusted void naughtyFunction() => corruptMemory();
> ```
The difference is that @system code is not callable from @safe,
but @trusted is. You can be as wrong as you want in @system code,
and it will not compromise @safe code unless someone uses
@trusted improperly.
> The difference is that in the allocator there's no
> user-provided `@trusted` attribute you can point to and say
> "this one has the problem".
In Richard Cattermole's hypothetical, the @trusted (or
@localsafe) attribute is in the implementation of the container;
for example:
struct Vector
{
RCAllocator allocator;
void[] memory;
// ...
~this()
{
// ...
() @trusted { allocator.deallocate(memory); }();
}
}
> We could require that any allocator that's supposed to be safe
> for reference counting must have a member function `@trusted
> @disable void refCountCertificate();`, with `@trusted`
> attribute being checked for. That way it's not possible to
> corrupt memory in `@safe` code without writing at least one
> `@trusted` function.
This would technically work, but I do not think I could look
someone in the eye who was new to D and explain it without dying
of embarrassment.
More information about the Digitalmars-d
mailing list