A little more context: I am updating github.com/bobg/modver to be generics-aware. This package can compare two versions of a Go module and tell whether a major, minor, or patchlevel version-number bump is needed, according to semver rules.

If two versions of a Go object differ only in the constraint on a type parameter, what should the result be? The answer depends on the type set implied by the constraint.

If the two type sets are identical, the result should be None. If the older type set is a strict subset of the newer type set, that is a backward-compatible change and the result should be Minor. Otherwise it's an incompatible change and the result should be Major.

I had hoped to use types.Identical and types.AssignableTo to distinguish these cases, but if I can't, what's the best way to do it instead? Must I write my own type-set-comparing logic, or is there something in the stdlib I can use?

Thanks...

CC @griesemer @findleyr

In the current language no variable can have the type comparable, so at least at present it doesn't necessarily make sense to call AssignableTo. On the other hand, Implements does make sense, but it also returns true for both directions.

The question you want to ask seems like a reasonable one but I don't know whether the go/types package supports answering that question yet.

This is simply a bug and needs to be fixed. Thanks for the report.

When we check whether a (a value of) type V can be assigned to a (variable of) interface type T (types.AssignableTo(V, T)), because T is an interface, we need to check if V implements T. In this specific case we need to check if the empty interface (any) implements comparable. The comparable interface is implemented by any type that supports == and !=. (Even) in non-generic Go, == and != can be used with a variable of interface type (even the empty interface!), it's just that we might get a run-time panic if the dynamic type doesn't support comparison with == and !=. Thus, any interface (including any) supports == and !=, which leads to the (admittedly counter-intuitive at first) conclusion that any actually implements comparable and thus any is assignable to comparable.

If comparable is used as (or embedded in a constraint), it is therefore ok to instantiate the respective type parameter with an arbitrary interface (that satisfies all the other aspects of the constraint), because comparison is always supported by all interfaces. However, when running that instantiated code, we may get a run-time panic if the dynamic type of the interface does not support comparison (as we do in regular Go).

In short, this is not a bug but simply a consequence of existing rules.

Leaving this issue open for now so we can close it with a CL that adds some more tests.

Change https://golang.org/cl/380654 mentions this issue: cmd/compile: all interfaces implement comparable (add tests)

any actually implements comparable

OK, I can buy that (though I don't love it).

But there's something that distinguishes any from comparable, otherwise the compiler would not report "invalid map key type K (missing comparable constraint)" for this code snippet.

type X[K, V any] map[K]V

Is that distinction surfaced in the stdlib? What is the right way to detect it? Will an explicit call to types.Comparable do the job? Or can there be other pairs of constraint types, not involving comparable, with a symmetrical Implements relationship but an asymmetrical "Satisfies" relationship? Do we need / can we get types.Satisfies?

In this code snippet, the type of K is a type parameter - the operations == and != are only available on K if it is comparable: type parameters are a new kind of type with their own new rules - operators on type parameters are only available if their constraints explicitly say so. The spec requires that == and != are defined on the key types for maps. If you make K comparable, it's still possible to instantiate X with an arbitrary interface.

types.Comparable will tell you for a type parameter if it is comparable.

There won't be a types.Satisfies, satisfying a constraint means exactly implementing the constraint interface; i.e., the function to use is types.Implements (possibly after instantiation of the constraint).

What is missing in the in-progress spec is not extra rules for this, just a sentence highlighting the fact that all interfaces implement comparable, as a consequence of pre-existing rules.

It is some weird to view any (as a value type) and comparable (as a type constraint) as the same thing.

It is not a problem to view any (as a type constraint) and comparable as the same thing.

Maybe the types package should add a function types.Subset(C1, C2 *types.Interface) function, for constraints.

Nobody is saying that any and comparable are the same thing. They are not the same as a type constraint, and if comparable is ever accepted as the type of a variable, they will not be the same as a variable type.

However, values of type comparable (if such values were permitted) could be assigned to variables of type any (because any value can be assigned to a variable of type any). And values of type any could be assigned to variables of type comparable (because any is an interface type, and all interface types are comparable). This doesn't mean that they are the same; it means that they can each be assigned to the other.

To put it another way, this code, which instantiates a type parameter of type comparable with the type argument any, is valid.

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

func EqAny(x, y any) bool {
	return Eq(x, y)
}

And values of type any could be assigned to variables of type comparable (because any is an interface type, and all interface types are comparable).

This listens some weird. An interface value may never box another interface value.
When an any value is assigned to a comparable, the dynamic value of the any value is actually assigned to the comparable.
If the assignment is allowed, then will a panic occur when the dynamic is incomparable?

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

func EqAny(x, y any) bool {
	return Eq(x, y)
}

This example is legal because any and comparable in it are two different things. any is a value type, which satisfies comparable, which is a type constraint.

On the contrary, the following code should not work:

func Eq(a, b comparable) bool {
	return a == b
}

func EqAny(x, y any) bool {
	return Eq(x, y)
}

I understand that a type constraint might be directly used as a value type (sum type) later.
But it is really weird that a subset constraint (here any) implements a superset constraint (here comparable).

Edit: here "subset" and "superset" mean rule set. If they mean type set, then comparable is the subset.

On the contrary, the following code should not work:

I disagree.

This code works today:

func EqIface(x, y any) bool {
    return x == y
}

That seems basically the same as the version that you wrote.

Different from a method set, a comparable just has an operator set.
I don't understand why an operator set could get special treatments over method sets.

type Comparable interface {
	==(another Comparable) bool
}

Yes, we could have gone that way in the language. But we didn't.

(Part of the reason we didn't is that the interface definition you wrote permits using the == method with any type that implements Comparable. But the actual == operator does not permit that; it only permits using the exact same type (or, in some cases, an untyped constant).)

I agree my above operator method definition is not perfect. It is just used to make the explanation.

And if comparable may be used as a value type and any implements it.
What should the following program print? true or false?
By the current rules, two answers are both reasonable.

var x any = []int{}
var c, ok = x.(comparable)
print(ok)

By the rules of type assertions, I think your code would have to print false.

You're right that it's an interesting case.

In the current implementation rule, if any implements comparable, compilers are able to evaluate ok as true, at compile time.

Change https://golang.org/cl/381435 mentions this issue: cmd/compile/internal/types2: use Checker.implements in operand.assignableTo

Change https://golang.org/cl/381896 mentions this issue: spec: add section on comparable constraint

This is now fixed in the type checker. What is outstanding is the documentation in the spec. Not a release blocker anymore.

@griesemer "... This is something we cannot change."
Why not? We can now still introduce a new notation like =! for this case that was not legal Go pre 1.18 while all previously working Go programs would still compile and 1.18+ programs will still remain fully backward compatible.

@tinytina2021 I'm not sure I follow: we cannot change the behavior of == and != for interfaces as that would invalidate existing programs. But we can have different rules for type parameters, which is what we're doing. I'm not sure how introducing =! (and what about the negation of =!?) would help or why it would be useful.

The implementation of AssignableTo has been fixed and https://golang.org/cl/381896 documents the behavior or comparable. Closing.

@griesemer Just to flag, the change so that any no longer counts as comparable makes it difficult to write generic code in some quite common situations

It kinda seems like this change has been made a little last-minute and without particularly widespread discussion, but may have a fairly significant impact on people's ability to use generics in Go

For example, when using golang-set, it's pretty reasonable that you might want to make a set containing any comparable type - e.g.:

	NewSetFromSlice[any](
		[]any{
			1,
			2,
			3,
			"test",
		},
	)

The code cannot be written as NewSetFromSlice[comparable]([]comparable{ - this results in the error interface is (or embeds) comparable compiler(ErrorCode(142))

So as far as I can see, it is no longer possible to write this code at all - though maybe I'm missing something obvious?

If you're firm that any will never implement comparable, maybe comparable should be allowed in non-type constraint interfaces?

Honestly, this seems significant enough to be a release blocker, although it probably could be fixed later without a breaking change

Edit: opened as a new issue - #51257 - as I appreciate this one has been closed for a couple of weeks now

I think the correct answer here is to allow comparable as a regular type. See #51257 for more.

Change https://go.dev/cl/401874 mentions this issue: spec: clarify type set and interface are different