Interface method names

April 11, 2023

Basic interfaces

The name of each explicitly specified method must be unique and not blank.

interface {
	String() string
	String() string  // illegal: String not unique
	_(x int)         // illegal: method must have non-blank name
}

These rules likely look familiar, from our discussion of struct field names, which must also be unique. But there’s a difference: The blank methods are not permitted!

Why is that?

Well, in effect, the blank identifier is write-only. That is, we can name things (types, variables, fields) with the blank identifier, but there’s no way (aside from reflection in a few cases) to reference these.

This means that an interface with a blank identifier would be impossible to use. Nothing could ever match it, and nothing could ever refer to the blank method(s). So, it’s just forbidden. And I’m sure we’re all happier for it!

Quotes from The Go Programming Language Specification Version of December 15, 2022


Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content


Method expressions, conclusion

Today we’ll finish our discussoin of method expression from Monday and Tuesday. Method expressions … Function values derived from methods are called with function call syntax; the receiver is provided as the first argument to the call. That is, given f := T.Mv, f is invoked as f(t, 7) not t.f(7). We’ve already seen examples of this, the last two days. But to be honest, you’re unlikely to use these types of functions very frequently.


Second rule of Selectors

Selectors … For a value x of type I where I is an interface type, x.f denotes the actual method with name f of the dynamic value of x. If there is no method with name f in the method set of I, the selector expression is illegal. type I interface { Greet() } type Person struct { Name string } func (p *Person) Greet() { fmt.Printf("Hello, %s", p.Name) } var I x x = &Person{} x.


Type parameters in method definitions

Yesterday we saw that when a method is defined on a generic type, the receiver must include type parameters. Now for all the relevant details: Method declarations … … Syntactically, this type parameter declaration looks like an instantiation of the receiver base type: the type arguments must be identifiers denoting the type parameters being declared, one for each type parameter of the receiver base type. The type parameter names do not need to match their corresponding parameter names in the receiver base type definition, and all non-blank parameter names must be unique in the receiver parameter section and the method signature.

Get daily content like this in your inbox!

Subscribe