go: spec: `any` no longer implements `comparable`

I think this issue should have gone through the proposal process. The type parameters design doc explicitly states:

The type set of the comparable constraint is the set of all comparable types.

The definition of “comparable” at the time that proposal was approved states (emphasis mine):

Interface values are comparable. Two interface values are equal if they have identical dynamic types and equal dynamic values or if both have value nil.

By those definitions, every interface type should be included in the type-set of comparable, and thus any — as an interface type itself — should be in that type-set.

Redefining comparable not to include interface types is a very late and drastic departure from the design that was approved in #43651.

I believe this is just a bug: When we check if a type implements comparable, we must always use the same criteria for comparability. In this case:

type T struct{ x any }

func main() {
	NewSetFromSlice([]T{
		{"foo"},
		{5},
	})
}

the type T is not an interface and the code is using the traditional (before 1.18) predicate to determine if T is comparable. It should be using an updated version.

I think this needs to be fixed for 1.18 otherwise we’ll have to maintain this inconsistency.

I agree that the long-term solution is to allow comparable as an ordinary type. See also my comment here:

Had we introduced a notation (some special mark) for interfaces for which we expect to use == and != in the beginning of Go, all this would have been a non-issue: clearly one wouldn’t be able to compare two interfaces that don’t support comparison. Such a mark would also have made it impossible to assign a non-comparable value to non-comparable interfaces, etc. Instead we relied on a run-time test, at considerable implementation cost, for that matter. This is something we cannot change. But generic code will now be type-safe with respect to this.

@billinghamj Note that Set is declared as follows:

type Set[T comparable] map[T]struct{}

A Set is a map, and maps are not comparable, they have never been. So you can’t use a Set (i.e., a map) as a key for another map. This is also not possible in non-generic Go.

FWIW I am not sure that []comparable really fixes the inconsistency. For example this works today:

type T struct{ x any }

func main() {
	NewSetFromSlice([]T{
		{"foo"},
		{5},
	})
}

It is odd that []T (where T contains any) is allowed but []any is not. It feels like an inconsistent cut-out. But I completely agree about waiting until after Go 1.18 to figure this out.

Is there any reason to believe we can’t relax this in a future release? Being conservative for now seems like the best answer.

Notably, if interfaces do not satisfy comparable, then a transition like this for sync.Map doesn’t work:

type MapOf[K comparable, V any] struct { ... }
type Map = MapOf[any, any]