“Make invalid states unrepresentable” is a type of fool’s gold. You don’t care that invalid states are unrepresentable, you only ever care that a specific insta

“Make invalid states unrepresentable” is a type of fool’s gold. You don’t care that invalid states are unrepresentable, you only ever care that a specific instance of your running program is very unlikely to enter an invalid state - and the difference between formally disallowing invalid states vs. test coverage that proves a reasonable likelihood of avoiding invalid states is huge. The extra code and conceptual complexity spent to make type designs that disallow invalid cases is a liability, it comes with its own bugs, maintenance and huge risks of premature abstraction and brittleness in the face of changing requirements. If it takes anything more than a simple enum-style menu of permitted options, then it’s a code small. Things like Scala case classes (especially with sealed behavior), or pattern matching against type constructors, or phantom types - these are all very bad ideas, where the costs far outweigh the benefits. Most of the time you can just ignore enforcement of assumptions, and add a few assert statements plus lightweight unit tests and integration tests that generate an abundance of real world example cases - and achieve all the safety you need for a fraction of the code & conceptual complexity and tech debt incurred by false promises of enforcing correctness with type system designs.