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
Comment From: 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.
Comment From: dominikh
@ianlancetaylor https://go.dev/play/p/ZPFH8EReq1R?v=gotip is what I had in mind.
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: zigo101
Should this be a 1.18 release blocker?
Comment From: 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.
Comment From: 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.
Comment From: gopherbot
Change https://go.dev/cl/387924 mentions this issue: doc/go1.18: document method set limitation for method selectors
Comment From: gopherbot
This issue is currently labeled as early-in-cycle for Go 1.19. That time is now, so a friendly reminder to look at it again.
Comment From: gopherbot
This issue is currently labeled as early-in-cycle for Go 1.20. That time is now, so a friendly reminder to look at it again.
Comment From: griesemer
Moving this to 1.23. We hope to lift this and related restrictions eventually (see also #63940).
Comment From: griesemer
Didn't get to https://github.com/golang/go/issues/63940, so moving this to 1.24 as well.