Go interfaces: implicit satisfaction and the non-nil nil

What it is

The specification defines an interface type as a type set; a variable of interface type can store a value of any type in that set, and such a type is said to implement the interface. Implementation is structural: *os.File implements io.Reader because it has Read([]byte) (int, error), not because it says so. Since Go 1.18 interfaces also serve as type constraints for generics, where they may list types and embed comparable. Type assertions (v, ok := x.(T)) and type switches recover the concrete type at run time. The Go FAQ explains the representation: an interface value holds a type and a value, and it is nil only when both are unset.

Why it matters

For someone used to duck typing this feels familiar, with one difference: the compiler checks the duck. Python's Protocol and TypeScript's structural types are the closest relatives. The representation has a consequence Python lacks: a *MyError pointer that is nil, returned as error, yields an interface with type *MyError and value nil, which compares unequal to nil. The FAQ shows exactly such a function and notes that it will always return a non-nil error.

How to apply

• Define interfaces where they are consumed, with as few methods as the consumer needs; the standard library's one-method io.Reader, io.Writer and fmt.Stringer are the model, and Effective Go's section on interfaces argues the same way.
• Accept interfaces in parameters and return concrete types from constructors; callers can then wrap or fake a dependency in tests without a mocking framework.
• Assert satisfaction at compile time with var _ io.Writer = (*Buffer)(nil) when a type is meant to implement something.
• Mind method sets: a method with a pointer receiver belongs to *T, not T, so a plain value of T does not satisfy the interface; the compiler says so.
• Return nil literally, never a typed nil pointer, from a function whose result type is error.

Pitfalls

Large interfaces force every fake to implement everything. Interfaces that exist only to enable mocking, with a single implementation, add indirection without a second consumer. any parameters push type errors from compile time to run time; generics with a constraint are usually the better tool. Comparing two interface values whose identical dynamic type is not comparable (a slice, map or function) panics at run time, and so does using such a value as a map key.