Would something like this work:
m1 := make(map[string]string)
m2 := m1
if &m1 == &m2 {
...
}
On Tue, Feb 11, 2020 at 5:50 AM roger peppe <rogpe...@gmail.com> wrote:
> 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/CAG%3Dmn_s25XcHKhOdPuZCDFMLM1v1O0z7S4i5wan9ZXiPCKVmsA%40mail.gmail.com.
