spec: Method sets section doesn't seem quite right for interfaces with type lists

[dominikh]

https://tip.golang.org/ref/spec#Method_sets says the following:

The method set of an interface type is the intersection of the method sets of each type in the interface's type set (the resulting method set is usually just the set of declared methods in the interface).

AFAIU, per

• The type set of a non-empty interface is the intersection of the type sets of its interface elements.
• The type set of a non-interface type term is the set consisting of just that type.

the type set of interface { S } for concrete type S is {S}. The intersection of the method sets is thus the method set of S. But that doesn't seem quite right. func foo[T S](x T) { x.Foo() } certainly doesn't compile. Was the intention to have an implicit, empty method set for the absent list of methods in the interface?

/cc @griesemer @findleyr

[ianlancetaylor]

I'm not sure I completely understand the premise here. This code does work: https://go.dev/play/p/RFUCmHLu964?v=gotip . Sorry if I'm missing something obvious.

[dominikh]

@ianlancetaylor https://go.dev/play/p/ZPFH8EReq1R?v=gotip is what I had in mind.

[ianlancetaylor]

Ah, right. Thanks. Certainly the method set of S includes Foo(). I suppose the question here is: what is the method set of T and therefore of x? The current spec doesn't seem to specify the method set of a type parameter.

[ianlancetaylor]

Or perhaps the call of x.Foo() is fine and this is a compiler bug (though perhaps not one that we should worry about for 1.18). After all, if all the types in a type set support a method, why not permit calling it?

[zigo101]

Maybe, the description should be changed to

... is the combination of explicitly specified methods and the union of the method sets of each embedding interface type ...

(edited)

BTW, the following line has become invalid inaccurate now:

In a slightly more general form an interface T may use a (possibly qualified) interface type name E as an interface element. ...

Here the word name has become unnecessary in 1.18.

[zigo101]

Should this be a 1.18 release blocker?

[griesemer]

@dominikh The intention (with type sets) has been to make this work, but we haven't gotten to it for 1.18. It's not a release blocker because there are trivial work-arounds: one can always wrap an interface with the necessary methods around the constraint (e.g. your example could be modified like this).

Given that we're very late in the release, we probably can't fix this in time (I'll have a look though, maybe it's trivial). We may end up documenting this as temporary restriction. Alternatively, maybe we can adjust the spec slightly and disallow this, but it needs some more thinking. Any less complexity is certainly appreciated.

[dominikh]

I think it'd be simplest to leave the spec as is, and document the restriction. The behavior as described in the specification certainly makes sense and is consistent with the rest of the language.