Ideas for a v2
Overall, this package has held up well. If we were to ever consider a v2, here are some changes:
- By default, always treat every variable as addressable, so that comparers and transformers that operate on a pointer can be used.
- Use generics where appropriate:
package cmp
func Comparer[T any](f func(T, T) bool) Option
func FilterValues[T any](f func(T, T) bool) Option
func Transformer[T, R any](name string, f func(T) R) Option
package cmpopts
func AcyclicTransformer[T, R any](name string, f func(T) R) Option
func IgnoreFields[T any](names ...string) Option
func IgnoreInterface[T any]() Option
func IgnoreMapEntries[K comparable, V any](f func(K, V) bool) Option
func IgnoreSliceElements[E any](f func(E) bool) Option
func IgnoreType[T any]() Option
func IgnoreUnexported[T any]() Option
func SortMaps[K comparable](f func(K, K) bool) Option
func SortSlices[T any](f func(T, T) bool) Option
It's unclear whether SortMaps and SortSlices should take a less function (i.e., func(T, T) bool) or a compare function (i.e., func(T, T) int) to match the current slices.SortFunc signature.
It would be good if we could control whether the library panics or returns an error -
Knative has wrapped this library to handle that https://github.com/knative/pkg/blob/d0a82f9cbb8f2f92ce8f130c701f2da29bb33109/kmp/diff.go#L41
https://github.com/google/go-cmp/issues/338#issuecomment-1750773032
@dsnet
v2 is roughly accepts backwards incompatible change.
So would be happy if rename cmp package name to something (e.g., gocmp, or gcmp means Google Compare library...?) for conflicts stdlib cmp package.