Basic interfaces

April 7, 2023

Basic interfaces

In its most basic form an interface specifies a (possibly empty) list of methods. The type set defined by such an interface is the set of types which implement all of those methods, and the corresponding method set consists exactly of the methods specified by the interface. Interfaces whose type sets can be defined entirely by a list of methods are called basic interfaces.

// A simple File interface.
interface {
	Read([]byte) (int, error)
	Write([]byte) (int, error)
	Close() error
}

So basic interfaces are just a list of methods. And as mentioned before, any type that implements all of those methods, satisfies the interface.

But perhaps the most important part of the above text is just mentioned in passing: The list of methods in an interface may be empty.

interface {}

is a perfectly valid interface. And as of Go 1.18, it has an alias: any.

The empty interface, as it’s called, can serve many purposes. It can act as a placeholder for any other value, since, logically, every value of any type has at least zero methods on it.

Newcomers to Go often abuse the empty interface, however. As the proverb says, “interface{} says nothing”.

Before using the empty interface, consider: Can you use some other type to more clearly express the intent of the code? This, of course, is more art than science, and takes practice.

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.