cmd/compile: incorrect type set intersection computation

[zigo101]

What version of Go are you using (go version)?

$ go version
go version go1.19.4 linux/amd64

Does this issue reproduce with the latest release?

Yes, also for tip.

What did you do?

package main

func main() {}

type C1 interface {
	comparable
}

type C2 interface {
	comparable
	[2]any | int
}

func G1[T C1](t T) {}
func G2[T C2](t T) {}

func F1[V [2]any](v V) {
	_ = G1[V] // error: V does not implement comparable
}

func F2[V [2]any](v V) {
	_ = G2[V] // okay (but should not?)
}

What did you expect to see?

Both F1 and F2 fail to compile.

What did you see instead?

F2 compiles okay.

My understanding is that the type set of C2 only contains int, because [2]any is not strictly comparable, though my understanding might be wrong.

[cuonglm]

F2 compile ok, because C2 is an empty type set.

There is no type that both implement comparable and is an array [2]any.

[ianlancetaylor]

Note that in 1.20 C2 is satisfied by [2]any, per #56548.

It's not clear to me why this compiles with 1.18 and 1.19. CC @griesemer .

[cuonglm]

@ianlancetaylor C2 is an empty type set, the same as:

type C2 interface {
    string
    int
}

[zigo101]

@cuonglm

,,, C2 is an empty type set.
There is no type that both implement comparable and is an array [2]any.

But why doesn't the type set of C2 contain int?

I looks the calculated type set of C2 in the following code is indeed [[2]any, struct{x any}, int], which is obviously wrong.

package main

func main() {
	var x struct{x any}
	var y [2]any
	G2(x) // okay
	G2(y) // okay
	var z int
	G2(z) // okay
}

type C2 interface {
	comparable
	[2]any | int | struct{x any}
}

func G2[T C2](t T) {
	// 1.20rc1 error message
	_ = t == t // invalid operation: t == t (incomparable types in type set)
}

[cuonglm]

@go101 the semantic for go1.20 was changed, see Ian's comment above.

[zigo101]

I read the new semantic changes several times. Maybe I still haven't got it.
I don't get why the type set of C2 is not [int]. I don't think it is relevant to the 1.20 semantic changes.

And per @ianlancetaylor 's

Note that in 1.20 C2 is satisfied by [2]any,

My understanding is that C2 is only satisfied by [2]any only when [2]any is used as a value type (but for the above example, it is not anyway), not a type constraint. (That is why the F1 function fails to compile, which is an expected behavior.)

[cuonglm]

You can see C2 as:

type non_comparable interface {
	[2]any | int 
}

type C2 interface {
	comparable
	non_comparable
}

non_comparable does not implement comparable, because not all types in the type set of non_comparable are comparable. So there's no type that both implement comparable and does not implement comparable, so C2's type set is empty.

See: https://go.dev/ref/spec#Type_constraints

[zigo101]

I don't think the interpretation is right, if the compilation behavior is right for the following program.

package main

func main() {
	var x int
	G2(x) // okay
	var y []byte
	G2(y) // error: []byte does not implement C2 ([]byte missing in ~int)
}

type C2 interface {
	comparable
	~int | ~[]byte
}

func G2[T C2](t T) {
	_ = t == t // okay
}

[atdiar]

@go101
(from my understanding)
The real constraint is interface{[2]any}
It has to implement comparable but does not implement the constraint strictly comparable. (easily understood since implementation is type set inclusion)

Strictly comparable is different from comparable in that it asserts that the members of its type set are themselves implementing comparable instead of just satisfying it.
(i.e. the members of stricly comparable are themselves strictly comparable)

According to my current reading of the spec at tip, strictly comparable does not matter here because [2]any is not an interface.
[2]any satisfies comparable because it has the comparison operators. We have type set inclusion. So the type parameter constraint you are using actually implements C2. All is fine.

The compiler is correct.

[zigo101]

Okay, now the only I don't understand is why the _ = t == t line doesn't compile? (edit: I'm still confused in several points, ;))

[cuonglm]

@go101 you're right. I was wrong that the type set is empty, it's actually contain [2]any and int. Running gotype with tracing enabled:

p.go:10:6:	-- checking func G2 (white, objPath = )
p.go:10:9:	.  type params = [T₁]
p.go:10:11:	.  -- type C2
p.go:10:11:	.  => C2 (under = interface{comparable; [2]any | int}) // *Named
p.go:10:17:	.  -- type T
p.go:5:6:	.  -- type set for interface{comparable; [2]any | int}
p.go:5:6:	.  => {[2]any | int}
p.go:10:17:	.  => T₁ (under = interface{comparable; [2]any | int}) // *TypeParam
p.go:10:6:	=> func G2[T C2](t T) (black)

[atdiar]

@go101 In that case, C2 is reducible/can be rewritten to interface{~int}.

Embedding the comparable constraint enforces that any type argument has to be(means "has to satisfy") comparable. Via the conjunction/embedding, C2 enforces that any potential type argument is comparable.

C2 is just not the canonical form of the expressed constraint. ~[]byte can be eliminated.

Passing a type inferred variable of type []byte to G2 doesn't compile (it's not comparable). It's normal. :)

[zigo101]

@atdiar
More specifically, I mean why the _ = t == t line in the following code doesn't compile.

type C2 interface {
	comparable
	[2]any | int | struct{x any}
}

func G2[T C2](t T) {
	// 1.20rc1 error message
	_ = t == t // invalid operation: t == t (incomparable types in type set)
}

[atdiar]

@go101 ah yes, you're right, I actually don't know. Looks like a bug to me as well.
cc @ianlancetaylor @griesemer