Add cmpopts.FilterValue

[dsnet]

cmp.FilterValues expects a function of the signature func(T, T) bool where the function is called with values from both the left argument and the right argument.

I propose the addition of cmpopts.FilterValue that is semantically equivalent to:

func FilterValue[T any](f func(T) bool) cmp.Option {
    return cmp.FilterValues(func(x, y T) bool {
        return f(x) && f(y)
    })
}

The current cmp.FilterValues is more powerful as you can make a filtering decision based on information from both values, but most usages of it want the logical AND of a single-argument predicate function. In fact, all of the usages of cmp.FilterValues in cmpopts would prefer to use a single-argument predicate function. Examples:

• go-cmp/cmp/cmpopts/equate.go

  Lines 26 to 31 in 6faefd0

  	func isEmpty(x, y interface{}) bool {
  	vx, vy := reflect.ValueOf(x), reflect.ValueOf(y)
  	return (x != nil && y != nil && vx.Type() == vy.Type()) &&
  	(vx.Kind() == reflect.Slice || vx.Kind() == reflect.Map) &&
  	(vx.Len() == 0 && vy.Len() == 0)
  	}

• go-cmp/cmp/cmpopts/equate.go

  Lines 60 to 62 in 6faefd0

  	func areRealF64s(x, y float64) bool {
  	return !math.IsNaN(x) && !math.IsNaN(y) && !math.IsInf(x, 0) && !math.IsInf(y, 0)
  	}

• go-cmp/cmp/cmpopts/equate.go

  Lines 85 to 87 in 6faefd0

  	func areNaNsF64s(x, y float64) bool {
  	return math.IsNaN(x) && math.IsNaN(y)
  	}

• go-cmp/cmp/cmpopts/equate.go

  Lines 104 to 106 in 6faefd0

  	func areNonZeroTimes(x, y time.Time) bool {
  	return !x.IsZero() && !y.IsZero()
  	}

• go-cmp/cmp/cmpopts/equate.go

  Lines 144 to 148 in 6faefd0

  	func areConcreteErrors(x, y interface{}) bool {
  	_, ok1 := x.(error)
  	_, ok2 := y.(error)
  	return ok1 && ok2
  	}

Alternatively, we could modify cmp.FilterValues to also accept a function of the form func(T) bool where it effectively performs the AND of the predicate function applies to both arguments.

\cc @neild

[neild]

Alternatively, we could modify cmp.FilterValues to also accept a function of the form func(T) bool where it effectively performs the AND of the predicate function applies to both arguments.

This seems simpler for the user and avoids introducing yet another place where people need to remember whether a function is in cmp or in cmpopts. Any reason not to do it this way?

[dsnet]

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 switch the API to use generics where sensible.

Thus, today's cmp.FilterValues would be written as:

func FilterValues[T any](func(T, T) bool) Option

If we were make it accept either func(T) bool or func(T, T) bool, I'm not sure how to do that with generics.

If we had golang/go#41716, I think we can do something like:

func FilterValues[T any](interface{ type func(T) bool, func(T, T) bool }) Option

where the argument is effectively a sum-type of either func(T) bool or func(T, T) bool.

avoids introducing yet another place where people need to remember whether a function is in cmp or in cmpopts

If/when golang/go#48305 gets accepted, I think we should merge cmpopts into cmp as there'll be sufficient godoc features to better control the presentation of the documentation in a way that's clean.

[dsnet]

It seems that we can do this with the following signature:

func FilterValues[T any, F interface{ func(T) bool | func(T, T) bool }](f F) Option

[dsnet]

I realized that we can't convert our existing functions to generics in a backwards compatible way.

Consider the following user code:

func WrapTransformer(fn interface{}) cmp.Option {
     return cmp.FilterPath(..., cmp.Transformer("", fn))
}

The fn passed in is a interface{} and we've lost all information about the original type. If we switch Transformer to be generic, then this won't build since we can't statically determine the type at compile time without rewriting all wrapper options in existence to also be generic (ain't gonna happen).