Union restrictions

General interfaces … Implementation restriction: A union (with more than one term) cannot contain the predeclared identifier comparable or interfaces that specify methods, or embed comparable or interfaces that specify methods. Or putting this another way: Unions (that is, interface type parameters with a | character), only work on interfaces defined by other type parameters. interface { int | float32 // Valid int | error // Invalid: error is an interface that specifies a method int | comparable // Invalid: comparable is not a type parameter-defined interface } Quotes from _The Go Programming Language Specification_ Version of December 15, 2022

Other

21 min watch


ChatGPT-4 vs ChatGPT-3 vs Go

ChatGPT didn't do so well when quizzed about Go. Can ChatGPT 4 do better?


Type parameter restrictions

We’ll get to a full discussion of type parameters later on, but knowing at least what they look like is useful for the next section. So here’s an example, used in the definition of a generic function: func min[T ~int|~float64](x, y T) T { In this example, min[T ~int|~float64] represents the type parameter. With that in mind… General interfaces … The type T in a term of the form T or ~T cannot be a type parameter, and the type sets of all non-interface terms must be pairwise disjoint (the pairwise intersection of the type sets must be empty).


Unions of type sets

General interfaces … Union elements denote unions of type sets: // The Float interface represents all floating-point types // (including any named types whose underlying types are // either float32 or float64). type Float interface { ~float32 | ~float64 } Here we see our first example of a union of type sets. The example shows an interface of all types with an underlying float type. The equivalent for integer types is a bit longer, due to the large number of distinct integer types in Go, but would look like:

Subscribe to Boldly Go: Daily

Every day I'll send you advice to improve your understanding of Go. Don't miss out! I will respect your inbox, and honor my privacy policy.

Unsure? Browse the archive.


Restrictions on underlying type terms

General interfaces … In a term of the form ~T, the underlying type of T must be itself, and T cannot be an interface. type MyInt int interface { ~[]byte // the underlying type of []byte is itself ~MyInt // illegal: the underlying type of MyInt is not MyInt ~error // illegal: error is an interface } Once again, the spec examples are pretty well explained. TL;DR; the ~ prefix must always be associated with an underlying data type.

How-Tos

28 min watch


I'm officially a Go contributor! (and you can be, too)

Learn how the Go proposal and change process works, with a real world example.


Interface examples with type elements

Let’s look at some interface examples from the spec: General interfaces … // An interface representing only the type int. interface { int } // An interface representing all types with underlying type int. interface { ~int } // An interface representing all types with underlying type int that implement the String method. interface { ~int String() string } // An interface representing an empty type set: there is no type that is both an int and a string.


Interfaces don't contain interfaces

As we learned recently, Go interface elements may contain a type term of a non-interface type. It’s worth re-iterating that these are non-interface types. In particular, as the spec states: General interfaces … By construction, an interface’s type set never contains an interface type. That is to say, that the following is invalid: type interface foo { /* some interface elements */ } type interface bar { foo } Actually, I lied.


"Duck Typing" defined

I’ve already introduced the concept of duck typing, but now we have more or less a formal definition: General interfaces … The quantification “the set of all non-interface types” refers not just to all (non-interface) types declared in the program at hand, but all possible types in all possible programs, and hence is infinite. Similarly, given the set of all non-interface types that implement a particular method, the intersection of the method sets of those types will contain exactly that method, even if all types in the program at hand always pair that method with another method.


Interface type sets

With what we’ve learned so far about interfaces, we can now draw some general conclusions about the precise definitions of an interfce’s type set. The spec summarizes nicely. General interfaces … Together with method specifications, these elements enable the precise definition of an interface’s type set as follows: The type set of the empty interface is the set of all non-interface types. The type set of a non-empty interface is the intersection of the type sets of its interface elements.


General interfaces

Today we’re venturing into generics territory. General interfaces In their most general form, an interface element may also be an arbitrary type term T, or a term of the form ~T specifying the underlying type T, or a union of terms t1|t<sub<>2|…|tn. We haven’t actually learned about type terms yet–they’re coming in a few weeks. But for now, the TL;DR is that they let us specify a type by its name, rather than by its method(s).