Limitations on methods, part 2

August 29, 2023

Continuining from yesterday, when we started disecting this section of the spec:

Method declarations

A receiver base type cannot be a pointer or interface type and it must be defined in the same package as the method.

Today we’re tackling the second limitation:

A receiver base type cannot be an interface.

At first this might seem a bit counter-intuitive… aren’t interfaces all about methods? Well, yes, but in the other directions. Interfaces are collections of methods. But you can’t define methods on interfaces. To be explicit, this is invalid:

type foo interface {
	Foo() error
}

func (f foo) Bar() {} // invalid receiver type foo (pointer or interface type)

If you want to extend the foo interface with the Bar() method, the proper way is to extend the foo type definition:

type foo interface {
	Foo() error
	Bar()
}

Now it’s up to any types that implement this interface to define a method Bar().

Quotes from The Go Programming Language Specification Version of August 2, 2023


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