Description
The spec does not permit blank (_) method names for interfaces:
The name of each explicitly specified method must be unique and not blank.
The compiler complains about such methods but still adds them to the method set, as evidenced by this program
type T interface {
_()
}
type I struct{}
var _ T = I{}The compiler complains that the I doesn't implement T because of the missing _ method, hence the method must be present in T. Interestingly, the modified program
type T interface {
_()
}
type I struct{}
func (I) _() {}
var _ T = I{}where I has a _ method, still results in the same error. This is due to the fact that _ methods cannot be found in I as they are never declared.
Furthermore, given the program
type A interface {
_()
}
type B interface {
A
_()
}the compiler as before reports errors about the _ methods being invalid but otherwise is quiet. Yet, the following version
type A interface {
_()
}
type B interface {
A
_(int)
}reports the error duplicate method _ because now the two _ methods have different signatures. While this is consistent with what we'd expect from any other method, it seems confusing.
For contrast, go/types never adds the _ methods which results in fewer errors.
See also $GOROOT/test/interface/explicit.go (at end) where there's an explicit test that nothing implements an interface with a _ method. Since it's not possible to declare such interfaces in the first place, it may be simpler to just ignore _ methods when encountering them in interface declarations, and then this last test would pass w/o error, and the above examples would only produce errors when the _ methods are declared.
I'd like to see compelling evidence for keeping the existing behavior.
cc: @mdempsky