For what it's worth: I'd argue comparing `reflect.ValueOf(a).UnsafePointer()` provides stronger guarantees of portability and correctness than comparing `*(*uintptr)(unsafe.Pointer(&a))`. Also, you should probably use `*(*unsafe.Pointer)(unsafe.Pointer(&a))` if anything. It does the same thing, when it works, but I'm not sure that the conversion to `uintptr` that is happening is guaranteed to work under a moving GC. A comparison isn't necessarily
arithmetic - and those rules are just what `gc` is specifying anyways, an implementation is free to choose others, in theory.
That's because the latter relies on maps being "pointer-shaped". In theory, an implementation might not represent a map as a plain pointer. Though I admittedly having trouble coming up with an alternative design.
Plus, the
documentation of `reflect.Value.UnsafePointer` *also* doesn't really say *what* the returned pointer is for a map and what its semantics are. But it seems somewhat safer to assume that an implementation that would *not* represent a map as a plain pointer, would implement `reflect.Value.UnsafePointer` in a way that still allowed you to compare them for identity purposes.
But, as you might be able to tell, all of this is a bit of a nitpick of how willing you are to make assumptions about reasonable ways an implementation might deviate from what they *have* to do. I'm pretty sure there is no way to compare map values that is keeping *strictly* in the bounds of well-defined behavior. I would, personally, feel comfortable using either and to just assume that I never have to run my code in a sufficiently wild implementation. And I'd probably try to benchmark/test if the `reflect` based version changes performance characteristics (I would assume it makes it easier for the map to escape, but maybe maps *always* escape anyways) and if not, use `reflect`.