don't do that?

this kind of thing is why deepcompare exists to begin with

It seems unrealistic to assume that everyone on a reasonably sized team knows all of the subtle edge cases to avoid and never makes mistakes

I can use reflect.DeepCompare(x, y) and live with false negatives, but maps will always use x == y and blow up for something as simple as adding a private cache or callback to a value.

I can nag everyone to use reflect.DeepEqual and live with some false negatives, but maps always use k1 == k2.

There are also significant performance and behavior differences between the two.

They are not inter-changeable, nor can one replace the other.

more specifically, it's really strange to hear of people doing equivalence checks on objects with structure. What are you expecting that comparison to do? I doubt it is doing what you think is happening, and is indeed risky of panics.

This is days later, sorry, but - you can't use an interface as a map key, so this shouldn't apply, right?

https://go.dev/ref/spec#Map_types says that is allowed.

> If the key type is an interface type, these comparison operators must be defined for the dynamic key values; failure will cause a run-time panic.

Is this really the case? Can you link to anything or an example on go.dev/play/ ?

I can find a mention of "cmp.Equal" having that behavior, but that's just a third-party package panic.

It's true, but you'd never really write code like this

https://go.dev/play/p/r9NkQb6bQTx

The problem also affects structs that happen to have a private callback or cache anywhere within.

Obviously `interface{}` values are not comparable?

The comparison is explicitly allowed in the language spec, there’s no warning for doing it, and it often works depending on the types. It’s a data-dependent runtime error, which is usually hard to guarantee test coverage for.

Link to an example? I don't think this is true, unless you're playing stupid games with your code, which wouldn't pass code review.