Joe Tsai

Thanks for looking into it. I tried to perform a repro with just the snippet you gave and it seemed to work properly. I could only test with the string...

Thank you for the bug report and reproduction. This is a good bug report. It's known that there are a few edge-cases that cause `cmp` to have pathological behavior (e.g.,...

The semantics of `reflect.DeepEqual` is not identical to `cmp.Equal` even without any options specified, so that approach won't work in the general case (it might work for your use case)....

The `cmp` package is a testing-first package, so precise printing of types is a high priority. I'm not sure I see how this helps since `value.TypeString` is still transitively called...

Can you point at concrete code? It's a bit esoteric to me that code would depend only on `cmp.Option` but not but not the rest of `cmp` functionality.

If there were a build tag to isolate tests, I'd be more open to something like this, but as it stands we're going to prioritize good reporting of types in...

At present, `cmp` has no special support for any type in the Go standard library. The original reason why `cmp` was invented was because Go 1.9 introduced monotonic clock readings...

You could imagine the following being added: ```go package atomic func (x *Int64) Equal(y *Int64) bool { return x.Load() == y.Load() } func (x *Int64) String() string { return fmt.Sprint(x.Load())...

In the case of `atomic.Pointer`, it is unclear whether `atomic.Pointer.Equal` should be a pointer comparison or deep comparison. Different use-cases are going to reasonably want different behavior. This perhaps suggests...

> Doesn't cmp.Diff already have an opinion about what equality of plain pointer fields means (compare nil vs non-nil, then what's being pointed to)? Perhaps, but I still stand by...