202506201106 Make invalid states unrepresentable

As software engineers, we should strive to make our own lives and those of our fellow developers easier. By easier, I mean we should make it easier to make good software that works, is reliable, does not have bugs, performs the expected function, is verifiably correct, and is easy to maintain and extend. One way we can accomplish these goals is by making invalid states unrepresentable.

Making an invalid state unrepresentable means that we cannot actually express or build our system if it would result in an invalid outcome. We take advantage of our language's toolbox (types, classes, names, modules, and whatever else) to build constructs that cannot be used incorrectly.

For example, we can make a class or type that cannot be instantiated if it would be in an invalid state. A classic concrete example is a non-zero positive number.

struct NonZeroPositive(u64);

impl NonZeroPositive {
    fn new(inner: u64) -> Result<Self, Error> {
        match inner {
            i if i > 0 => Ok(Self(i)),
            _ => Err(Error)
        }
    }
}

This seems like extra work for representing something that we can easily use other number types (e.g., u64) for, but the value comes from the knock-on effects of adding constraints that reduce our power.¹ We know every time we have a NonZeroPositive that it will necessarily be non-zero and positive. We don't ever have to check that constraint again and can use that type in ways that you couldn't use a possibly zero number (e.g. as a denominator) without introducing bugs or invalid states.

There are many ways to make invalid states unrepresentable:

• The newtype pattern²³⁴
• The typestate pattern⁵
• Pre- and post-condition assertions⁶
• Invariant assertions
• Constructors, setters, and getters
• Strong and/or static type systems
• Parsing instead of validating⁷

This is a massive topic, and this note isn't meant to be exhaustive. Instead this should be a jumping off point for more investigation.