This episode is for subscribers only. To access it, and all past and future episodes, become a subscriber today!See subscription optionsorLog in
Sign up for our weekly newsletter to be notified of new episodes, and unlock access to any subscriber-only episode of your choosing!Sign up for free episode
We have talked about algebraic data types a number of times on this series, and we feel it helps wipe away some of the complexity in the language because we can see the simple math that lies underneath. For example, we saw that structs in Swift behave a lot like multiplication does from algebra, and that enums behave a lot like addition. And knowing that we could refactor our data types to simplify them without changing their intrinsic structure, or we could refactor them to remove invalid states.
We want to take this idea a step further. We want to say that the connection between Swift’s data types and algebra’s operations is so foundational that we should be emboldened to transfer concepts that are currently defined only on structs over to enums, and vice versa. This will help us see that there are a lot of lots of helpful operations on enums that Swift could be providing to us, but isn’t yet. But maybe someday!
So, let’s get started. We want to begin with a quick refresher on algebraic data types. We still highly recommend people watch our previous episodes (part 1 🆓, part 2, part 3) to get a serious, in-depth look, but this refresher will at least make sure we are all on the same page when it comes to algebraic data types.
A nice feature that Swift structs have is “properties.” You can access the fields inside the struct via dot syntax, for example
view.frame.origin.x. Enums don’t have this feature, but try to explain what the equivalent feature would be.
Swift enums are sometimes called “tagged unions” because each case is “tagged” with a name. For instance,
Optional tags its wrapped value with the
some case, and tags the absence of a value with
none. This is in contrast to “union” types, which merely describe the idea of choosing between many types, e.g. an optional string can be expressed as
string | void, and a number or a string can be expressed as
number | string.
What can an tagged union do that a union can’t do? How might
string | void | void be evaluated as a union vs. how might it be represented as an enum?
Either type we use in this episode is the closest to an anonymous sum type that we get in Swift as it has no semantics, but it only supports two cases. What are some ways of supporting an “anonymous” sum of three cases? What about four? Or more? Is it possible to support three or more cases using just the
Our introductory episode on algebraic data types. We introduce how structs and enums are like multiplication and addition, and we explore how this correspondence allows us to refactor our data types, simplify our code, and eliminate impossible states at compile time.
What does the Swift type system have to do with algebra? A lot! We’ll begin to explore this correspondence and see how it can help us create type-safe data structures that can catch runtime errors at compile time.
TypeScript has a feature closely related to enums and anonymous sum types. It is called “union types”, and it also allows you to express the idea of choosing between many different types.
TypeScript’s type system is also flexible enough to emulate’s Swift’s enums, but anonymously! Swift enums are sometimes called “variants” or “tagged unions” because each case is “tagged” with a label: for instance, the
Optional type is tagged with
An in-depth look at the differences between sum types and union types.
OCaml supports anonymous sum types in the form of “polymorphic variants,” which can describe a single, tagged case at a time.
A Swift community Twitter thread about anonymous sum types.