Structural vs Nominal Typing

When code passes a value of type A where B is expected, the checker has to decide whether that is allowed, and there are exactly two families of answer. A structural checker asks whether A has everything B requires: the same members, at compatible types, recursively. A nominal checker asks whether A was *declared* to be a B — by being it, extending it, or implementing it. Nothing about the members enters into the second question.

The consequence people notice first is accidental compatibility. In TypeScript a { x: number; y: number } is a Point, and so is a Vector, and so is the result of an object literal somebody wrote inline in a test — because all three have the members Point requires. In Java, a class with exactly the fields of Point is not a Point and never will be, no matter how identical it looks.

The consequence that matters more is what a type name *means*. In a nominal system a name is an identity, so it can carry an invariant: if the only way to construct a ValidatedEmail is through a constructor that validates, then having one is evidence. In a structural system a name is an abbreviation for a shape, so it carries no evidence at all — anyone can produce a value with that shape without going anywhere near your constructor.

Neither answer is the better one in general, and both exist for good reasons. Structural typing is what lets a checker be retrofitted onto a language whose values were never declared — see [[gradual-typing]]. Nominal typing is what lets a type name mean something the compiler will enforce.

Go is the clearest illustration because it made the two choices separately. Named types in Go are strictly nominal: type Celsius float64 and type Fahrenheit float64 are different types, and assigning one to the other is an error even though both are a float64 underneath. That is nominal typing doing exactly the job it is good at.

Interfaces in Go, on the other hand, are satisfied structurally and implicitly. A type implements io.Reader by having a Read([]byte) (int, error) method; it never says so, and it can implement an interface defined in a package it has never imported. That is structural typing doing exactly the job *it* is good at, and it is the reason Go code can define narrow interfaces at the point of consumption rather than the point of definition.

The split is a design worth stealing conceptually: nominal for data, where identity and invariants matter, structural for capability requirements, where the consumer should be able to state what it needs without the producer having to agree in advance. Languages with only one relation approximate the other with extra machinery — traits with blanket implementations, adapter classes, branding.

The motivating case is boring and expensive. A UserId and an OrderId are both strings. Every function that takes one takes a string. Somewhere in a five-argument call, two of them get swapped, and the type checker — which has been asked whether a string is a string — says yes. The bug is a database lookup returning nothing, or worse, returning somebody else's record.

A nominal language solves this with a newtype: struct UserId(String) in Rust, a record wrapper in Java, a type Celsius float64 in Go. The wrapper has a distinct identity, so the swap is a compile error, and in most implementations the wrapper is free — a single-field struct has the same layout as its field.

In a structural system you have to manufacture the identity, and the standard technique is branding: intersect the underlying type with a phantom property that no real value has and no other type can produce. Because the checker compares shapes, adding a shape nothing else has is enough to make the type incompatible with everything else. The property is never written at runtime; it exists only so the structural comparison fails.

The cost of branding is that construction now needs a deliberate escape hatch — usually a single cast inside a validating constructor — and that the resulting type prints badly in errors and in hover text. Both are worth it at boundaries where identifiers are passed around, which is most of them. It is the same argument as [[nullability]] and [[gradual-typing]]: buy the guarantee once at the edge, and let everything inside rely on it.

Structural checking is a graph problem. Deciding whether a large object type is assignable to another means walking the members, recursing into their types, and handling recursive types by assuming the relation holds while computing it. Real implementations memoise aggressively and still spend meaningful time here; deep generic types multiply the work, and this — together with intersections, from [[intersection-types]] — is where slow TypeScript builds come from.

Nominal checking is close to free. Two type identifiers are equal or they are not; the subtype relation is a small precomputed set of edges. That is why nominal languages can afford to check enormous programs quickly, and why their error messages are short: there is nothing to explain beyond "these are different types".

The API consequence runs the other way. In a nominal system the declared relationships are part of your public surface: adding an interface to a published class is additive, removing one is breaking, and a consumer cannot make their type satisfy your interface without editing their type. In a structural system there is no declaration to break — but adding a required member to an interface breaks every implementor at once, and nobody has to have told you they were an implementor. Structural systems have more implementors than you know about, which is precisely their strength and precisely their versioning hazard.