Recursive interfaces

May 8, 2023

Check out this week’s episode of the Cup o’ Go podcast: What the ʕ◔ϖ◔ʔ? New merch, TDD book interview with Adelina Simion, and more

You can probably guess Go’s rules about recursively embedding interfaces. In short: It’s not allowed.

General interfaces

An interface type T may not embed a type element that is, contains, or embeds T, directly or indirectly.

// illegal: Bad may not embed itself
type Bad interface {

// illegal: Bad1 may not embed itself using Bad2
type Bad1 interface {
type Bad2 interface {

// illegal: Bad3 may not embed a union containing Bad3
type Bad3 interface {
	~int | ~string | Bad3

// illegal: Bad4 may not embed an array containing Bad4 as element type
type Bad4 interface {

Note however, that, an interface method may refer to the interface itself. This is perfectly valid:

type Fooer interface {
	Foo() Fooer

In fact, it’s actually quite common. You’ll see this pattern with chainable methods. An example can be found in the package’s Handler type:

type Handler interface {
	/* snip */

	// WithAttrs returns a new Handler whose attributes consist of
	// both the receiver's attributes and the arguments.
	// The Handler owns the slice: it may retain, modify or discard it.
	WithAttrs(attrs []Attr) Handler

Here we see that a Handler implements a WithAttrs method that in turn returns a Handler, meaning it is possible to chain these:

	var h slog.Handler
	h = h.WithAttrs(/* ... */).WithAttrs(/* ... */)

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

Share this

Related Content

Embedded interfaces

Embedded interfaces In a slightly more general form an interface T may use a (possibly qualified) interface type name E as an interface element. This is called embedding interface E in T. The type set of T is the intersection of the type sets defined by T’s explicitly declared methods and the type sets of T’s embedded interfaces. In other words, the type set of T is the set of all types that implement all the explicitly declared methods of T and also all the methods of E.

Operator constraints

Last week I inconspicuously skipped over one sentence in the spec, the last sentence in the section on Operands, and jumped straight ahead to the section on Qualified identifiers. This is because the sentence didn’t make immediate sense to me, and I needed time to research it. I’ve done that research now, so, let’s jump back and cover the missed territory. Operands … Implementation restriction: A compiler need not report an error if an operand’s type is a type parameter with an empty type set.

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.