I believe that the main reason that equality isn't defined on maps (and slices) is to preserve the future possibility that equality might work at a whole-value level rather than on a reference level. I suspect that one of these days a final decision will be made...
On Mon, 10 Feb 2020 at 23:42, 'Kevin Regan' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I just ran into this... ...makes me like go a little less. > > > On Tuesday, August 7, 2018 at 6:34:03 AM UTC-7 mi...@daglabs.com wrote: > >> Sorry for bumping a very old thread, but I absolutely disagree with the >> people stating that this problem is contrived, and I got here from a Google >> search, so this might be relevant for some people. >> >> A very real use-case for reference-comparing maps is when testing >> .Clone() methods. You want to make sure that the clone is an actual clone, >> and that all the properties of the cloned object are also a clone, etc. In >> these cases you want to reference-compare everything. >> >> That said, reflect.ValueOf(xxx).Pointer is more than sufficient for this >> use-case. >> >> >> On Monday, July 15, 2013 at 3:50:01 AM UTC+3, Yi DENG wrote: >>> >>> There're always something that is not comparable. You can consider map >>> as one of this. If you have to check, use the pointer form. >>> >>> David >>> >>> On Saturday, July 13, 2013 7:35:55 PM UTC+8, Jsor wrote: >>>> >>>> I ask for maps because for slices this seems potentially problematic: >>>> what does "same reference" entail for a slice? Overlapping underlying >>>> arrays? Same starting pointer regardless of whether their len matches? Same >>>> start, end, len, and cap? And so on. Though I guess "reference-equality" >>>> would be pretty well defined for channels. >>>> >>>> However, for maps determining "sameness" at a reference level seems >>>> like a much more well defined question, and a much simpler one to answer. >>>> Yet I can't figure out a good way to do it. Perhaps with >>>> reflect.Value.UnsafePointer (would that even work)? Either way, that seems >>>> like overcomplicating things. The "easiest" way to do it seems to be >>>> something like this, dreamt up on the go-nuts IRC when I asked this: >>>> http://play.golang.org/p/6Ffxfx7zBb >>>> >>>> But I think we can all agree that that's a rather silly and limited >>>> solution (and to be fair wasn't suggested in earnest). >>>> >>>> I can see why == isn't defined on maps, too many people would likely >>>> mistake it for a deep equality test (if that was indeed the reason), but it >>>> seems like there should be some semi-trivial way to see if two map >>>> variables refer to the same map. Perhaps a need just wasn't seen for such >>>> an operation? Maybe it's really a more difficult/expensive test than I >>>> assumed? >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a1f4e265-4523-41be-a67a-f43610fd430a%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/a1f4e265-4523-41be-a67a-f43610fd430a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJhgacgt5ddXTGEr5nXxS3UCxRqcBkzZcyhYU70jbcejT0r87A%40mail.gmail.com.
