Suggestion: Add Nullable<T> and Optional<T> to lib.d.ts

[jaufgang]

There have been a number of issue threads discussing adding nullable types (most notably #7426 and #7488) and the idea of adding them to the core TypeScript Language was ultimately rejected.

However, it was also suggested in that issue that type mappings could be added to lib.d.ts

type Nullable<T> = T | null;
type Optional<T> = T | undefined.

But then the issue was closed and the suggestion seems to have been dropped. (see #7426 (comment) by @mhegazy )

Nullable<T> is even mentioned in https://www.typescriptlang.org/docs/handbook/advanced-types.html alongside Partial<T>, as well as Readonly<T>, Pick<T, K extends keyof T>, and Record<K extends string, T>. It is confusing when reading that document that Nullable<T> isn't in the core library and needs to be added to your project if you would like to use it.

To me it seems like it should be a logical and uncontroversial choice to add these type mappings. They are tiny additions to the library, and they provide a nicer syntax (IMHO) than explicitly using T | null or T | undefined.

[DanielRosenwasser]

I'm still not sure I see a huge benefit to adding it for everyone. Here's a few reasons why

1. If it's an argument of fewer characters, then null | T is already shorter than Nullable<T>.
2. Using the term Optional is a layer of cognitive indirection for differentiating between | null and | undefined. Being explicit is more helpful here.
3. It's arguable whether there should be a T | null | undefined alias as well, so if you want another alias to satisfy that, you've exacerbated the previous point.
4. Problems with find-all-refs and the like can be fixed.

Nullable<T> is even mentioned in https://www.typescriptlang.org/docs/handbook/advanced-types.html

Note that Nullable on that page is not the same as the Nullable that you've described, and it's probably a poor name to use in the documentation.

I do understand a general desire to have these coming from other languages that have a core set of utility types built in, but overall, I don't think think the lack of these aliases has been a major problem in TypeScript.

[jaufgang]

It isn't about fewer characters, and I would agree that the lack of these aliases is not a major problem.

To me it just seems that Nullable<T> and Optional<T> are a more intuitive way of expressing these types than as an explicit union.... "It's type T but it doesn't have to have a value" vs "It's type T, or else it could also be undefined".

Idunno, maybe it is just a bias coming from other languages but it just feels like these are missing things that should be there.

[kitsonk]

I think part of the challenge though would be that some people would assume that if you use Nullable<T> or Optional<T> that TypeScript would guard you against that, when in fact it would only do so if you were using --strictNullChecks. So by default, they wouldn't actually do anything.

[mhegazy]

The conclusion a while back in #7426 was that | null and | undefined explicitly was the best way forward. Our experience since has validated that conclusion. the two extra types are not too long to write, nor they are hard to understand; and thus the additional layer of indirection using a type alias seems to be unwarranted here.

Again, if you find these aliases helpful, you are more than welcome to define them locally and use them. our experience however does not suggest there is a need for them in the wider community at the time being.