The comparable interface

August 7, 2023

Are you as curious about Fuzzing in Go as I am? On today’s live stream, I’ll be live coding my way through John Arundel’s 4-part series on Go Fuzzing. I hope you’ll join me!


Today we’re learning about the predeclared comparable interface. But before this discussion makes sense, we should jump ahead to one key definition. That of the concept of “strictly comparable”:

A type is strictly comparable if it is comparable and not an interface type nor composed of interface types.

With this in mind, the rest of the discussion on the comparable interface should make more sense…

Type constraints

The predeclared interface type comparable denotes the set of all non-interface types that are strictly comparable.

Even though interfaces that are not type parameters are comparable, they are not strictly comparable and therefore they do not implement comparable. However, they satisfy comparable.

int                          // implements comparable (int is strictly comparable)
[]byte                       // does not implement comparable (slices cannot be compared)
interface{}                  // does not implement comparable (see above)
interface{ ~int | ~string }  // type parameter only: implements comparable (int, string types are stricly comparable)
interface{ comparable }      // type parameter only: implements comparable (comparable implements itself)
interface{ ~int | ~[]byte }  // type parameter only: does not implement comparable (slices are not comparable)
interface{ ~struct{ any } }  // type parameter only: does not implement comparable (field any is not strictly comparable)

The comparable interface and interfaces that (directly or indirectly) embed comparable may only be used as type constraints. They cannot be the types of values or variables, or components of other, non-interface types.

So what are the key points to pull out of this?

  • The comparable interface is pre-defined, and is implemented by types that are strictly comparable.
  • The comparable interface can only be used as a type constraint. You cannot create a variable of type comparable.

Tomorrow we’ll see how type constraints are satisfied, which will shed a bit more light on this topic.

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

Share this

Related Content

Satisfying a type constraint

Satisfying a type constraint A type argument T satisfies a type constraint C if T is an element of the type set defined by C; i.e., if T implements C. As an exception, a strictly comparable type constraint may also be satisfied by a comparable (not necessarily strictly comparable) type argument. More precisely: A type T satisfies a constraint C if T implements C; or C can be written in the form interface{ comparable; E }, where E is a basic interface and T is comparable and implements E.

Type constraints

Are you as curious about Fuzzing in Go as I am? On Monday’s live stream, I’ll be live coding my way through John Arundel’s 4-part series on Go Fuzzing. I hope you’ll [join me!](https://youtube.com/live/VKV-sFFeSQw Type constraints A type constraint is an interface that defines the set of permissible type arguments for the respective type parameter and controls the operations supported by values of that type parameter. TypeConstraint = TypeElem . If the constraint is an interface literal of the form interface{E} where E is an embedded type element (not a method), in a type parameter list the enclosing interface{ … } may be omitted for convenience:

Generic functions as operands

Operands … An operand name denoting a generic function may be followed by a list of type arguments; the resulting operand is an instantiated function. So first off, recall that an operand may be a function literal: var x = func() { /* ... */ } Or a variable that represents a function: var F = func() { /* ... */ } var f = F // <--- `F` is a variable that represents a function Or another expression that evaluates to a function: