proposal: go/types: add StrictlyComparable function

[kwjw]

Proposal Details

Background

From #56773:

Generics introduced the constraint comparable which denotes the set of all types which are strictly comparable. An API may define an exported type T which may be strictly comparable (see #56548 for terminology) and such a type T may successfully be used as type argument for comparable type parameters elsewhere.

It's possible to change T without visible API change so that it's not strictly comparable anymore.

Whether an exported type is strictly comparable should be considered a part of its API. As such, it would be useful if this property were exposed through go/types.

Determining whether a type is spec-comparable is exposed via types.Comparable:

go/src/go/types/predicates.go

Lines 155 to 158 in b199d97

	// Comparable reports whether values of type T are comparable.
	func Comparable(T Type) bool {
	return comparableType(T, true, nil, nil)
	}

In the call comparableType(T, true, nil, nil), the boolean parameter indicates spec-comparability (true). Setting this parameter to false indicates strict comparability.

Proposal

Add the following function to go/types:

// StrictlyComparable reports whether values of type T are strictly comparable
// (https://go.dev/ref/spec#Comparison_operators).
func StrictlyComparable(T Type) bool {
	return comparableType(T, false, nil, nil)
}

[gabyhelp]

Related Issues

• cmd/api: api checker should check types for change in comparability #56773
• proposal: spec: add comparable w/o interfaces #49587 (closed)
• proposal: spec: allow interface types to instantiate `comparable` type parameters #52509 (closed)
• proposal: type parameters are comparable unless they exclude comparable types #52614 (closed)
• proposal: spec: permit values to have type "comparable" #51338 (closed)
• proposal: spec: add new constraint kind satisfied by types that support == (including interface types) #52531 (closed)
• proposal: spec: permit non-interface types that support == to satisfy the comparable constraint #52474 (closed)

Related Code Changes

• spec: introduce notion of strict comparability
• spec: add section on comparable constraint
• [dev.go2go] go/types: prevent comparable interface from being used outside constraints

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

[ianlancetaylor]

CC @griesemer @adonovan @findleyr

[kwjw]

CC @jba

apidiff could make use of a function like StrictlyComparable. If a previously spec-comparable struct is changed to no longer be comparable, apidiff reports this as an incompatible change. There should be a similar rule for maintaining strict comparability.

[findleyr]

I agree that we should add this. In principle, we should support any type predicate that appears in the spec.