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