What is Structural Typing?

Aliases

In this view, the names of types in structural types are effectively only aliases. The send_login_reminder function could be equally written, in pseudo-code, like this:

function send_login_reminder( recipient as {
	String name
	String email
})

The symbol User is nowhere to be found, yet the function is semantically identical.

To dive deeper into types, take a look at my article how compilers do type conversion.

Type Plurality

With nominative types, every object has a specific type, or set of types, that identifies it. When we create a User object, that object is actually of the type User, and nothing else. Perhaps that User inherits from a base-class, in which case it is also of that type. But that’s it. It’s not any of the other types that we define in our code-base. In this way, we can speak of the object as having a particular type, and checks like instance of make sense. Nominative types have real identities.

With structural types, objects don’t have a strict set of types that identify it. Any object matches any type, across all our code and all libraries, that has a structurally compatible form. For example, if I declare this type:

class HasName:
	String name

Any object which has a String name field, regardless of how it was created, or which types were involved in its creation, will now also match the HasName type. This means that objects don’t have a limited set of types, and can instead match many types in the code base. From this view, we can’t speak of objects as having a particular type, and checks like instance of are nonsensical — structural types don’t have identities.

Inclusive, excess properties

Structural type systems also tend not to care about excess properties. For example, perhaps we have a Company type as below.

class Company:
	String name
	String email
	Address address
	Region region

We can call the send_login_reminder function with objects of this type as well.

company = load_company("highland")
send_login_reminder(company)

Whether this makes sense in our code depends on whether or not companies can login. This may or may not be a defect that a structural type system would not catch.

In contrast, if we had a send_catalog function, we probably want it to work for User and Company types, which, with no type changes, works fine in structural typing. In nominative typing, we’d have to introduce an interface, or shared base class, that exposes the common name and email.

Duck Typing

Duck typing is the quintessential aspect of dynamic typing. Effectively there are no static types, and whether code is valid depends solely on whether the statements executed at runtime make sense for the values involved. Despite this dynamic nature, we can still talk about the types a function takes, albeit in a less strict way.

For example, consider our familiar function and rough implementation:

def send_login_reminder( recipient ):
	message_raw = load_reminder_template
	message = message_raw.format( recipient.name )
	send_email( recipient.email, message )

Looking at the body of this function, we can tell that it works so long as the recipient argument has both a name and email property. Despite it being dynamic, we can talk about the expected type of the recipient argument — being explicit or inferred tends not to change the fundamental way in which a type system works. For example, if we were a type checker, we would infer the following:

interface _send_login_reminder_argument_0:
	String name
	String email
	
def send_login_reminder( _send_remind_email_argument_0 recipient ):
	...

This looks and behaves much like the User type works in a structural type system. To see how it differs, we need to introduce a conditional branch.

def send_login_reminder( recipient ):
	message_raw = load_reminder_template
	message = message_raw.format( recipient.name )
	if recipient.email.endswith( ".special.com" ):
		send_special_email( recipient.email, recipient.token, message )
	else:
		send_email( recipient.email, recipient.priority, message )

What would the type of recipient have to look like now?

interface _send_login_reminder_argument_0:
	String name
	String email
	possibly Integer token
	possibly Integer priority

The possibly pseudo-code is not the same as optional field, since in the code there is a path that definitely needs the token and one that definitely needs the priority, but not both. We can still express this as a structural type, but perhaps not the one you’re expecting. I’m shortening the names here for clarity.

interface _base:
	String name
	String email
	
interface _variant_0 extends _base
	Integer token
	
interface _variant_1 extends _base
	Integer priority
	
interface argument_0 = _variant_0 or _variant_1

In this code or means a union type, where the type can be one or the other. We can create structural types that define the inferred type of a duck-typed function. But the resulting type can become quite complex, with every branch introducing another union of similar types. They aren’t that useful as types. This is why, when migrating from duck-typing to structural typing, we’d probably opt for simple optional types for token and priority.

Protocols

Python adopted a nominative type system in 3.5. You’re still allowed to use duck-typing, but you can also create statically typed functions and variables. And despite duck-typing being close to structural typing, they instead went with nominative typing. There are many reasons for this, and I’ll get to it in a future article.

Typed Python retains the ability to do structured types in the form of a Protocol. This is a special symbol which makes a class behave like a structural type. Consider the following example, with the nominative types first.

@dataclass
class User:
	name: str
	email: str
	
def send_login_reminder( recipient: User ):
	...
	
	
jack = load_user('jack')
send_login_reminder(jack)  // good

lilou = {
	'name': 'Lilou',
	'email': 'lil8493@mail.com',
}
send_login_reminder(lilou)  // not allowed

The recipient argument of the function must take an explicit User type. Neither a tuple nor another class with the same fields will work. It has to be an actual User object. But we can do something similar to the EmailRecipient used as an example before, using the Protocol class.

class EmailRecipient(Protocol):
	name: str
	email: str

def send_remind_email( recipient: EmailRecipient ):
	...

Now, although the User class doesn’t mention EmailRecipient at all in its declaration, it still matches, since the form is the same. Protocol creates structural types. PEP 544 calls this “Structural subtyping” or “static duck typing”. Though, as mentioned before, the structural types you define by hand will be stricter than the inferred structural types arising from duck typing.

Templates

In C++ templates allow defining a function where the types differ depending on how it is called. As a simple example, perhaps we have a function that compares the ages of two objects.

template<typename ItemT>
bool is_younger(ItemT a, ItemtT b) {
    return a.age < b.age;
}

This can be called with two objects of the same type, as long as they have an age defined, and that age can be compared. The age may be an integer, or it could be a date object, anything that defines a less-than operator. Arguments a and b have inferred types; in pseudo-code we could replace ItemT with an explicit structural type.

interface LessThanT:
	bool operator < (LessThanT a, LessThanT b)
	
interface ItemT:
	LessThanT age

Now, this isn’t how C++ works. It doesn’t infer this type. Instead, it replaces all the types used at the point where the template is instantiated, and ensures they’re valid. Similar to how Python also didn’t infer its duck-types, instead it simply runs the code sees if an error occurs.

Constraints and Concepts

The trouble with templates in C++ is that if you had a type error within template code, the error message could be long, hard to read, and hidden deep within a call-tree of templates. The same type of error happens with duck-typing in Python, where deep in some library code you get a type-mismatch.

For years, the C++ community has debated the idea of explicit structural types in the form of concepts and constraints. Unfortunately, I have had not the chance to work with C++ since they’ve been introduced, so I’m going to defer to a reference page.

To cope with C++’s static types, the concept system is stricter and more flexible than Python’s — of course at the typical C++ expense of added syntax.

Enums and fundamental types

Enums are different in TypeScript. Since they are effectively strings, and structural typing would treat all strings the same, it’d make for relatively useless enum types. TypeScript broke from their structural typing to say that enum is nominatively typed. An enum of one type, will not match an enum of another type, even if they are both strings, even if they share the same keys and values.

The structural nature of fundamental types is harder to explain, and the reason I’ve stuck with class types for this article. For example, take a simple “integer” type. What is the name, and what is the form of this type? Here, the term “integer” refers to both the name and its form, which can make it confusing.

Let’s consider instead an alias, using the TypeScript number type.

type AgeT = number

function is_younger(a: AgeT, b: AgeT) { ... }

AgeT is another name for number. As structural types don’t care about names, this shouldn’t be relevant. The is_younger function can be called with any numbers, and it could be declared with number instead of AgeT. The type AgeT is an interchangeable alias with number.

Some languages offer strong aliases, where, in this example, a number would not be passable to an AgeT type: you’d have to explicitly convert. Python has a natural way to do this with TypeVar.

This is how enum differs in TypeScript. Two structurally identical enums, even with the same keys and values, are distinct. They are nominatively typed, not structurally.

enum CallResponse {
	no = 0
	yes = 1
}
enum OtherResponse {
	no = 0
	yes = 1
}

function Accept( r: CallResponse ) { ... }

Accept( CallResponse.no )  // valid
Accept( OtherResponse.no ) // invalid

Knowing this, with some trickery, you can mimic nominative types in TypeScript using enums. It’s possible to create a distinct type for AgeT like Python allows, though it’s not pretty.

Excess Properties

Having structural types as the basis to an entire language’s static type system has some issues. I’m going to do a followup about these problems in TypeScript, but for now, let’s look at one common case: excess properties.

We said before that structural types care only if the required properties are present, not if there are too many of them. Since this leads to a common class of errors, TypeScript disallows excess properties in places it can easily detect them. For example, think back to our send_login_reminder, here converted to TypeScript.

type User = {
	name: String
	email: String
}

function send_login_reminder( recipient: User ) { ... }

send_login_reminder({ 
	name: 'Maxine',
	email: 'max4775@mail.com',
	token: 123,
})

This call to send_login_reminder is invalid, as TypeScript notices the extra token property and realizes it will not be used. As TypeScript lacks named arguments, as JavaScript does, using argument types to pass named arguments is common. This extra check in TypeScript ensures you only pass arguments the function knows about.

This check is limited and was previously lost if you assigned the arguments to a variable. For example, passing a Company object to something expecting a User object would work. The excess properties check is a narrow exclusion to the structural typing rules. as const was further introduced to try to retain this property check over several statements.