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
The spec does not permit blank (
_) method names for interfaces:The compiler complains about such methods but still adds them to the method set, as evidenced by this program
The compiler complains that the
Idoesn't implementTbecause of the missing_method, hence the method must be present inT. Interestingly, the modified programwhere
Ihas a_method, still results in the same error. This is due to the fact that_methods cannot be found inIas they are never declared.Furthermore, given the program
the compiler as before reports errors about the
_methods being invalid but otherwise is quiet. Yet, the following versionreports 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/typesnever 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