Joe Tsai

> Maybe it would be best to remove purego from go-cmp. To my mind, the main benefit of this build tag is when you're providing a pure-Go implementation which does...

> Is this possible to express? Technically, yes. The entire `cmpopts` package is implemented in terms of the public API of `cmp`. The feature that seems most useful to you...

For the composibility problems with `cmpopts.FilterField`, this is a discussion I had with Roger on Slack some time ago: * @rogpeppe: I was just trying to do something with cmp...

If possible, I'd like to keep the API surface of `cmp` smaller. I wonder if I can make use of the [`testing.Verbose`](https://golang.org/pkg/testing/#Verbose) flag as a signal to increase the arbitrary...

> I don't think that is a great idea, because that would mean verbose mode is required to get useful output on failures which effectively means tests need to be...

> It is still under the control of the test author, because the test author decides what types to compare or not? The author might not be able to control...

No, I'm not. Feel free to a take a shot at it. Thanks!

> Any reason not to do it this way? I don't have a strong preference of the approach taken. This might be a pie-in-the-sky goal, but it'd be nice to...

It seems that [we can do this](https://gotipplay.golang.org/p/52sfJLaKUEx) with the following signature: ```go func FilterValues[T any, F interface{ func(T) bool | func(T, T) bool }](f F) Option ```

I realized that we can't convert our existing functions to generics in a backwards compatible way. Consider the following user code: ```go func WrapTransformer(fn interface{}) cmp.Option { return cmp.FilterPath(..., cmp.Transformer("",...