proposal: cmp: Equal

[jimmyfrasche]

Proposal Details

I find myself writing this a lot lately. Sometimes multiple times in a module because I don't want to export it or bother with creating internal/ packages just for this.

package cmp

func Equal[T comparable](a, b T) bool {
  return a == b
}

This comes up whenever you have Op and OpFunc where the latter variant takes an equality function. The body of Op just calls OpFunc with some local copy of the proposed.

Even with the shortest possible syntax proposed in #21498 this would still be (a, b) => a == b vs cmp.Equal[T] and T would often be inferred as this is basically always used as the argument to a function.

[gabyhelp]

Related Issues and Documentation

• proposal: testing/cmp: add new package #45200 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

A minor nit: in order to correspond to cmp.Compare, the implementation in the cmp package should be something like

func Cmp[T comparable](a, b T) bool {
    if isNaN(a) && isNaN(b) {
        return true
    }
    return a == b
}

[dsnet]

Wouldn't that have unexpected behavior for composite types like arrays, structs, and interfaces?

Equal([2]float64{123, 456}, [2]float64{123, 456}) // true
Equal([2]float64{nan, 456}, [2]float64{123, 456}) // false
Equal([2]float64{nan, 456}, [2]float64{123, nan}) // true

As far as I can tell, our options are:

1. restrict the constraint to ordered (which greatly limits it's utility),
2. don't explicitly treat NaNs as special (which causes inconsistency with Compare),
3. accept this weird edge case, or
4. use reflection to introspect on composite types on a per-field or per-element basis (which imposes a dependency on reflect for a relatively simple package).

[ianlancetaylor]

Good points. I don't know if there is a reasonable way to do this entirely correctly.

[jimmyfrasche]

My understanding was that the special case for NaNs in Compare was to make it total so it could be used by sorting. Is there any such necessity for equality?

Regardless, it seems like either choice would require specific documentation to say that it surprisingly doesn't conform to Compare or that it surprisingly does.

Personally I think the best thing to do would be not conform so that it's nothing more than a convenient way to write T's == function. If special NaN handling is added I'd have to continue writing little ==s functions to avoid having to mention the NaN issues in documentation where the assumption is the normal rules of equality are in effect.

[ianlancetaylor]

I think it's pretty confusing if cmp.Compare(a, b) == 0 but cmp.Equal(a, b) returns false. That just seems like a hazard waiting to trip people up.

[jimmyfrasche]

I retract the proposal then. It's of no use to me if it's not regular ==.