Build fluency in the vocabulary of types built from combined fields or a choice among distinct named variants.
0 / 5 completed
1 / 5
At standup, a dev mentions defining a type as either a combination of several fields all present at once, or as one of several distinct named variants, each of which may carry its own different data. What is this kind of type called?
An algebraic data type is exactly this: a type built either as a combination of several fields that are all present at once, called a product type, or as a choice among several distinct named variants, each potentially carrying its own different data, called a sum type. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This combined-fields-or-choice-of-variants structure is exactly why algebraic data types let a compiler check, at compile time, that every possible variant of a value has actually been handled.
2 / 5
During a design review, the team models a network response as an algebraic data type with distinct success and failure variants, each carrying different data, instead of a single struct with optional fields for both cases. Which capability does this provide?
Modeling the response as an algebraic data type with distinct variants provides compile-time guarantees that every variant is handled explicitly, since the type system can check, wherever the response is consumed, that both the success and failure variants are accounted for, rather than relying on a convention about which optional fields are meaningful together. A single struct with optional fields for both cases leaves that association as an unenforced convention, risking a spot that reads a success-only field without checking whether the response was actually a failure. This compiler-checked, distinct-variants structure is exactly why algebraic data types are favored for modeling a value that's genuinely one of several distinct shapes.
3 / 5
In a code review, a dev notices a network-response type is modeled as a single struct with a bunch of optional fields, some meaningful only on success and others only on failure, relying purely on convention to know which fields apply together. What does this represent?
This is a missed opportunity to use an algebraic data type, since a single struct with a bunch of optional fields relies purely on an unenforced convention to know which fields are meaningful together, when modeling the response as distinct success and failure variants would let the type system itself enforce that a success variant's fields and a failure variant's fields can never be mixed up or accidentally read from the wrong case. A cache eviction policy is an unrelated concept about discarded cache entries. This convention-instead-of-compiler-enforcement pattern is exactly the kind of risk a reviewer flags when a value is genuinely one of several distinct shapes.
4 / 5
An incident report shows a bug reached production because code read a failure-only field from a network-response struct without first checking whether the response had actually failed, since the struct's optional fields relied purely on convention rather than any enforced structure. What practice would prevent this?
Modeling the response as an algebraic data type with distinct success and failure variants lets the type system itself prevent code from reading a failure-only field without first confirming, through the language's variant-checking mechanism, that the response actually is the failure variant, which is exactly the fix for the bug described in this incident. Continuing to rely on a struct with loosely related optional fields regardless of how easy it is to misuse them is exactly what let this bug reach production. This distinct-variants, compiler-enforced structure is the standard fix for exactly this class of bug, where a value is genuinely one of several distinct, mutually exclusive shapes.
5 / 5
During a PR review, a teammate asks why the team reaches for an algebraic data type with distinct variants instead of a single, more flexible struct with optional fields that could technically represent the same information. What is the reasoning?
An algebraic data type with distinct variants lets the compiler enforce that a value's fields only ever match its actual variant, catching mismatches, like accidentally reading a failure-only field on a success value, at compile time, while a struct with loosely related optional fields only catches that kind of mistake, if at all, at runtime through a bug report or a defensive check someone remembered to write. The tradeoff is that modeling distinct variants requires a language and type system that supports algebraic data types well, and can feel like more upfront structure than a single flexible struct. This is exactly why algebraic data types are favored whenever a value is genuinely one of several distinct, mutually exclusive shapes.