Understanding types as sets

♪♪ Hello, everyone. My name is Tizian Cernikva Dragomir. Welcome to my talk, TypeSets Sets. A little bit about myself first. I work on the JavaScript infrastructure team at Bloomberg. I contribute to the TypeScript compiler. And if you've heard about me, you've probably heard about me from Stack Overflow, where I answer a lot of questions about TypeScript.

So I want to start off this talk with a very simple question. What is a type? It's often very simple questions that can allow us to gain new insight. When we first start to learn programming, we will look at types as something that we associate with a variable. We will probably also learn that this data type has something to do with the way that data is represented in memory. So for example, integers are represented on 32 bits, strings are a sequence of characters, objects are also represented in memory in a particular way. So we come out with the impression that a type is representation and behavior, behavior meaning the operators that can manipulate those values. But there is also a different way to look at a type, namely, as a value space.

So a type is a set of values that the variable can possess. And let's look at some of the primitive types in TypeScript and how those relate to this definition. For example, the type number is the set of all floating point values. The type string is the set of all text values. The type Boolean is the set of values true and false. There are also some special types in TypeScript, namely the never type, which, since it has no possible values that can exist at runtime, it represents the empty set. And the unknown type, which represents the set of all possible values in Javascript. So let's take this new way of looking at types and try to apply them to some types we probably already know. Let's try to create a type that describes a set with a single value. In TypeScript, such types are denoted by their associated values. So we can define a type that is the value Yes, 1, or True. And once we've defined these types, if we associate them with a variable, then that variable can only contain the value that is part of that set. So, for example, if we associate Yes with a variable, it can only hold Yes. It can never hold the value No or any other string value. Now, literal types are not particularly useful until we associate them with one of the basic operations that we can do on sets, namely unioning. When we create a union of two existing sets, we create a new set that contains the values of both of the original sets.

So, similarly, in Typescript, if we create a union from our three existing types, using the pipe operator, what will happen is that we create a new type that can have values from all three of these constituent types. So our new type can contain the values 1, True, and Yes, but it can't, for example, contain the value No.

Let's take a look at the other operation we can do on sets, namely intersection. Now, let's say we have two primitive types, namely string and number, and we want to see what the intersection of these two types would be. Well, what value at runtime is both a string and a number? The answer is that there is no such value. So these two sets are actually completely disjointed. So their intersection would be the empty set. And TypeScript represents the empty set through the never type. So this intersection would be Never.

But let's see if we can do something more useful with intersections. Let's say we have this union of literal types. And we would like to extract the string components of this union. How could we use intersections in this case? Well, if we were to intersect boolean-like with the string set, what values would be in this intersection? And the answer is just the values Yes and No. The other values wouldn't fill the criteria, right? 0 and 1 are not string types, neither is True and False. So if we create this type, TypeScript will agree with us and say, Yes, just strings is Yes and No. And similarly, we could extract numbers if we intersect with number. We could also extract the booleans if we intersect with boolean.

Now something very interesting happens here since boolean just contains True and False. Since the result of this intersection would just be True and False, what just boolean ends up being is, of course, just the boolean type because boolean is just the Union of the literals True and False. But let's take a look at why exactly this works. Why does TypeScript perform this reduction? Well, TypeScript will try to bring all types that contain Union and Intersection operators to a canonical form. Namely, it will try to express our type as a Union of intersections, and it will apply distributivity to arrive at this result. So, for example, if we take the just strings type we created before, what TypeScript will first do, it will expand out that Union. And it will then try to take the intersection and move it closer to each one of the Union constituents. So we will get this type. What happens now? Well, if we take the intersection of String, which contains all string values, and of the type Yes, which is the set of just the Yes value. What do we get? Well, the answer is we just get the Yes value. We get Yes out of this. So we don't have to keep all of this around, we can just leave the Yes type alone. What about No? Well, the situation is similar.

No and String will just result in No. What about the intersection of Zero and String? Well, the value Zero, which is in the set denoted by the literal type, has nothing in common with the string type. So the result is the empty union, which is, of course, Never. And the same is true for 1, True and False. All of these will result in Never types. So this is what we're left with after this reduction of intersections.

What happens now? Well, if we union with the empty set, the empty set will add nothing to our set. It is the same as if we hadn't done that operation. So we can just remove all those unions with Never and we're left with Yes or No.

OK, let's look at object types next. What does an object type define? Well, it defines a set of object values that must have the members defined by the object type. Now, crucially, what an object type does not do is it does not prevent other members from being present on the object. So what do I mean by this? Let's have an example. Let's look at a person type which has a name property and let's have a function that takes a parameter of this type. What can we pass in? Well, we can pass in an object that has fewer properties. The name property is required by the person type. We can obviously pass in an object that has the name property. That's fine. But we can also pass in an object that has more than that that has the name property and has the age property. Now TypeScript is perfectly happy to accept this.

Now, there is one exception to this is the behavior that's called access property checks, and this is when you actually do get an error if you try to assign an object literal with more properties to a parameter or a variable that has a specific type. Now this behavior only kicks in if the object literal is fresh, namely if you're creating it right there, and it's part of the pragmatism of TypeScript. It's something that TypeScript does, even though it's not necessarily consistent with the rest of the type system, but it does catch a certain class of errors that would make life more difficult for developers if it didn't catch.

So within the set defined by this object type, we might have objects that just have the name property, but we also have objects that have the name property and might have any number of other properties. Now an interesting consequence of this is the behavior of object.keys, which I'm sure is surprising to a lot of developers. object.keys will return a string array, which means that we actually can't use the result of object.keys to index back into the object we got the keys from. So p of key here will give an error. Now I'm sure this is a very frustrating behavior, it's very frustrating for me, and what people usually do is they just add a type assertion and say as key of whatever we passed it. And probably a lot of people think, well, TypeScript is still a new language, maybe this is an oversight, they just haven't gotten around to fixing it. I know I have thought that at first, and I know a lot of people submit pull requests to try to fix this, but this is actually not an oversight, this is intentional.

And the reason is, that we can actually pass in objects that have more than the keys of a person. So what happens if we pass in the object P1, which has a name property and an age property? Well, the for loop is going to take the first key, which is name, is going to uppercase it, everything will work fine, but then it's going to have the age key, and when it indexes with the age key it's going to get a number, which doesn't have the toUpperCase method, and this will fail at run-time. So, if object.keys were to return an array of whatever keys we passed in as a type, we might actually at run-time get more keys than we bargained for, and this might lead to run-time errors. And this is the reason object.keys has the type it has, because if it didn't, if it returned an array of key of whatever we passed in, we might actually get run-time errors that we weren't expecting, and run-time errors in a program that fully type checks.

Let's move on to unions of objects. What do these mean? Well, let's take an example. Let's say we have two object types, and we want to take their union. Well, this means that our new set, our union set, will have object values that might have a name property or might have an ID property, but we don't know exactly which one. So this means that it's not safe to access either of these properties because they might not be present. One of them will be, but we don't know which one. If these types would have had some property in common, for example, description, then that property would be safe to access because we can say for sure that it has to be present on all object values inside this set. And this is again a source of confusion for many newcomers to TypeScript because the union operation is named for what it does to the set of values, not necessary to what it does to the members because unions will allow access to an intersection of members. But again, the operation is named for what it does to the sets of values described by these types.

What about intersections of object types? Well, they suffer from a similar confusion. Namely, if we take the intersection of these two sets, what we will have in the intersection is object values that have both name and ID. And since they have both of these properties, it's safe to access either of them. So, intersection of object types will intersect the sets defined by the types and will result in a new type that has a union of members. But again, the operation is named for what it does to the sets, not for what it does to the members. So, again, unions and intersections, a lot of people have the feeling at first that these are badly named because, well, unions we have an intersection of members, while for intersections we have a union of members. But these, again, are not named for what they do to the members, they're named for what they do to the sets of values.

Let's see if we can use the same trick we used on unions of primitive types to filter out a discriminated union. And here we have a discriminated union that has two constituents, one of type square and one of type circle. And the question is how can we extract just the circle component. And we could of course use a conditional type, that is definitely the preferred way to do this, but intersections also can do the job. And mostly they give out the same results. So what type could we intersect this union to only preserve the type that has type circle? And the answer is that we can intersect with another object type, that has a property of type circle. And this will actually preserve just the component that we are interested in because it is, the intersection, does not contain any of the objects that could have type square. So let's see how this could work. Well, TypeScript will try to do the same thing it does for the union of primitives, namely to try to bring it to the canonical four. So first of all TypeScript will expand that shape into the union that it actually is.

And it will then bring the intersection closer to each of the constituents of the union. So what happens now? Well, TypeScript will notice that the second constituent of this union has an intersection that has type both circle and type square. So this property type will have to be circle and square at the same time. Now, the intersection of these two types is actually the never type. There is no possible value that can be at the same time the constant circle and the constant square. So it will reduce this object type to something that has a property of type never. And then it will notice that, okay, this itself is the equivalent to never because there is no value, no object value that can have a property of type never. So this is also never. Now, after this is done, we're again left with a union with never. So this can just be eliminated. And we're left with this intersection. Even though this type will, in effect, work the same as our circle type, the one that has the radius as well, it is different from what we would get from a conditional type, from the extract conditional type. But again, it does the job just as well. And it illustrates the way intersections work and can work for object types.

Another question I want to ask is, what is a base type? And again, this is one of those questions that can offer more insight. Especially, what is a base type when we talk about sets? And again, our intuition is shaped by nominally typed languages. We can always check the type definition in the nominally typed language for an extends clause or an implements clause. And this usually gives us a pretty good idea, especially for classes, what the base class is. So, for example, in this case, in C++, we can just check what comes after the colon, and we see that dog extends animal. Same in Java, we can see that dog extends animal, so animal is the base type of dog. And same for C Sharp. But, what does it actually mean to have a variable that is typed as a base type? What can that variable actually hold? Well, it can hold an instance of an animal, but it can also hold an instance of a dog, or an instance of a cat, or an instance of any subtype of animal. So, generally speaking, if you have a variable that is typed as a base type, it can hold instances of any subtype. So, within our animal type, the values that are possible are instances of animal, of dog, of cat, and indeed, since TypeScript is a structurally-typed language, a structurally-typed type system, any compatible object that fits the description of animal can also be present inside the set. So, what conclusions can we draw from here? Well, a base type describes the set that contains all subtype values, and a subtype is always a subset within the base type.

So, given all of this, how can we find the base type of this object type, for example? Well, the question becomes, what sets is this set a subset of? Well, we could look at this set as a subset of the set described by an object type that just has the name property, but we could also look at it as a subset of the type that has just the age property. So, what conclusions can we draw from this? Well, a type can have multiple base types in TypeScript, and they don't necessarily need to be spelled out. They just work out this way, because the sets are included in one another. More than that, considering optional properties, the number of base types could actually be infinite, because if we ask TypeScript, does a type that has just age and name extend a type that has name and optional description, TypeScript will say, yes. And this is pretty clear, because the type with name and description also includes any objects that have name and age, because again, it's just a subtype of this bigger type. So, indeed, we can actually find any number of base types to our type.