String as variable and mapped key type behaves differently

Question

Consider this:

type N = never;
type A = 'A';
type B = 'A' | 'B';
type S = string;

type RN = Record<N, string>;
type RA = Record<A, string>;
type RB = Record<B, string>;
type RS = Record<S, string>;

declare let n : N;
declare let a : A;
declare let b : B;
declare let s : S;

s = b;
b = a;
a = n;

declare let rn : RN;
declare let ra : RA;
declare let rb : RB;
declare let rs : RS;

rn = rs;
rs = rn;

rs = ra;
ra = rb;

Let < be the subtype operator. Obviously, N < A < B < S because n is assignable to a is assignable to b is assignable to s.

So, I would expect RS < RB < RA < RN.

However, from the example you see that RB < RA < RS because rb is assignable to ra is assignable to rs. Moreover, RS and RN seem to be equivalent types.

I would assume that string can be seen as the union type of all string literal types. So actually RS should be equal tonever since it’s impossible to have an object with properties for all possible string literals that exist (taking infinite space). Call this the complete object.

However it looks like RS is actually equivalent to the empty (RN) and not complete object.

Why is string behaving like never in Record?

Answer 1

Mapped types like the Record<K, V> utility type map string and number literal keys to individual properties, so Record<"A" | "B", string> is equivalent to {a: string; b: string}.

But keys of wide, non-literal types like string itself, or number, or pattern template literal types like `foo${string}` (as implemented in microsoft/TypeScript#40598) are mapped to index signatures. From the documentation for index signatures:

Sometimes you don’t know all the names of a type’s properties ahead of time, but you do know the shape of the values. In those cases you can use an index signature to describe the types of possible values.

So index signatures do not really represent "complete objects" with all possible keys of the relevant type, like an infinite intersection of all single-key objects {a: string} & {b: string} & {c: string} & ... & {foo: string} & ... {blahblah: string} & ....

(Aside: you said a complete object would be equivalent to never because it's not possible. But that's not really accurate. A Proxy object could easily be made to conform to this type. Even if it were not possible in JavaScript, it wouldn't be obvious that you'd want a type system to treat it as if it were never, without having some sort of explicit axiom about infinity, and then you'd have to figure out how to do that without prohibiting recursive data types.)

Anyway, index signatures are more like constraints on properties. An index signature of the form {[k: IndexType]: ValType} means "if the object has a property key of type IndexType, then such a property will have a value of type ValType". In some sense, it's more like the infinite intersection of all single-key objects with optional properties, like {a?: string} & {b?: string} & {c?: string} & ... & {foo?: string} & ... {blahblah?: string} & ...

---

Of course it's more complicated than that, since the compiler has not traditionally treated index signatures and optional properties the same.

Before TypeScript 4.1, index signatures would always let you read properties and get a value even though I just got finished explaining how they are more like optional properties. There were lots of complaints about this, and so TypeScript 4.1 introduced the --noUncheckedIndexedAccess compiler flag, which added undefined to the domain of index signature property values when reading, but not when writing. It's not enabled by default, even with --strict, because while it's more type safe, it turns out to be annoying in any scenario where people index through arrays or objects... code like for (let i=0; i<arr.length; i++) {arr[i]} or Object.keys(obj).forEach(k => obj[k]) should technically show arr[i] and obj[k] as being possibly undefined, at least without having a way to track the identity of i and k instead of just the type.

Before TypeScript 4.4, optional properties were treated as having undefined as part of their domain both when reading and writing. People complained about that a lot too, so TypeScript 4.4 introduced the --exactOptionalPropertyTypes compiler flag which preserved undefined on reads, but rejects writing to a property with undefined. This is also not included with --strict, since something like foo.bar = foo.bar is now considered an error if bar is optional.

If you enable both of those compiler flags, then index signatures and optional properties have similar behavior, although I'm sure more edge cases exist.

---

Anyway... Record<string, string> is equivalent to {[k: string]: string}) while Record<never, string> is equivalent to the empty object type {}. These are not identical types, but they are mutually compatible due to rules having to do with implicit index signatures as implemented in microsoft/TypeScript#7029.

There's a lot to unpack there too, and one could go on for quite a while about weak type detection, excess property checking, and the interaction between index signatures and interface types (see microsoft/TypeScript#15300). I'm going to stop now, though, since this answer is already long enough.

Answer 2

I would assume that string can be seen as the union type of all string literal types. So actually RC should be equal to never since it’s impossible to have an object with properties for all possible string literals that exist (taking infinite space).

This is the crux of the issue. A type Record<K, V>, and in general any type with an index signature, is supposed to mean objects whose keys are the values of the type K, such that if obj: Record<K, V> and k: K then obj[k] is of type V. If K is a type with infinitely many values, this is impossible in practice for the reason you wrote. So if we're being totally formal, then it's not possible to construct a value of type Record<K, V>,* so if Typescript were totally sound then Record<string, V>, and index signatures, would not be useful.

But Typescript is not totally sound, nor is it meant to be:

TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe. When a type system has this property, it is said to not be “sound”. The places where TypeScript allows unsound behavior were carefully considered, and throughout this document we’ll explain where these happen and the motivating scenarios behind them.

So, index signatures and Record work the way they do because it is useful to programmers who write Javascript code which assumes objects behave that way. Real Javascript code often uses objects as dictionaries, and often uses keys which are known to be present without handling the case where the key is not present.

For a sound alternative to Record<string, V>, you should write something like {[k in string]?: V} so that the type system explicitly knows that not all possible keys may be present in the object. In this case, when you access obj[k] it will have type V | undefined instead of V, and you will have to handle that possibility in your code (e.g. by narrowing with an if statement to check if the value is undefined).

---

^{*For technical reasons, that's not the same as Record<K, V> being equal to never when K is infinite. It is semantically entailed in the sense that those two types have the same value sets, but not syntactically entailed in the sense that Typescript treats them as assignable to each other (because it doesn't). Typescript has no rule to reduce Record<K, V> to never when K is infinite; I don't think Typescript keeps track of whether types are infinite in the first place.}