allow safety checks to compare the identity of`std.mem.Allocator`s

[190n]

I'm working on getting Bun ready for Zig 0.14. We have an unmanaged container for borrowed subslices of strings, which uses one of the bits in the len to store whether it needs to be freed. In debug builds, CowSlice also stores an allocator so that, even though it is unmanaged, it can make sure you don't try to free it with the wrong allocator.

However, I understand that comparing the ptr field on an Allocator is unsound because some implementations set it to undefined. I see that this approach was maintained in #22691, instead of the counter-proposal to set unneeded ptr fields to null instead. We can of course compare only the vtable field instead, but that makes the safety check weaker, because it would consider two different instances of the same kind of allocator to be equal (e.g. two arena or fixed buffer allocators). I don't see a way to provide the strongest possible safety guarantees without sometimes comparing undefined pointers.

This safety check seems like it might be useful for std's unmanaged containers as well. Is this a use case that should be supported?

[rohlem]

We can of course compare only the vtable field instead, but that makes the safety check weaker, because it would consider two different instances of the same kind of allocator to be equal (e.g. two arena or fixed buffer allocators).

It's a bit more effort, but if you have a registry of valid vtable pointers that maps to
information of whether the ptr field will be valid/sensible or not,
you can compare instances for those allocator types (identified by their vtable pointer) that do.

Allocators where ptr is unused, by their definition, don't really have the concept of an "instance".
(Though you could manually impose one by setting their ptr field to some fabricated pointer value, I guess.)

EDIT: At least that seems sensible to me in userland;
if such an approach is sanctioned by maintainers as well, we could standardize it in std as well.
(Although at that point we've re-introduced canonical comparability,
so I'd maybe question the decision against just making ptr optional.
It could be debug-only without changing the type,
but I personally think optionality changing between build modes would be acceptable too.)