[Feature Request] Add types to specify nullable/maybe values

[lkster]

Suggestion

🔍 Search Terms

• nullable type
• defined type
• maybe type
• nullable values
• defined values
• undefined values

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I'd like to have type aliases that specify whether type is nullable or probably undefined. Something like:

type Nullable<T> = T | null;
type Maybe<T> = T | undefined;

Just in case - I wouldn't compose those two unless it's a third type (MaybeNullable?). Lot of projects try to omit null and use undefined instead. Having type which says something can be both would be useless in such projects.

📃 Motivating Example

TypeScript has NonNullable type which is mostly useless with strictNullChecks option enabled. On the other hand there are no types to specify nullable or probably undefined type aliases. While we can just type type | null or type | undefined, it's more readable, faster and cleaner to do that with type aliases.

💻 Use Cases

Instead of:

let nullableValue: string | null;
let maybeValue: number | undefined;

function getDisplayName(): string | undefined {
  // ...
}

We can have more readable alternatives:

let nullableValue: Nullable<string>;
let maybeValue: Maybe<string>;

function getDisplayName(): Maybe<string> {
  // ...
}

[fatcerberus]

See #41901 (comment) for why this likely won’t be implemented.

[lkster]

See #41901 (comment) for why this likely won’t be implemented.

What you referenced is totally different thing. I'm not requesting for ? or any other type extension to cover | null or | undefined which would extend syntax in any way. As I understand:

1. It's not obvious whether it's "nullable" or "undefinable"
2. It can be confusing taking TypeScript's syntax into account (? is used next to variable name in some cases like interface fields hence it would be confusing to use it next to type name in other situation).

The thing I'd like to see are simple type aliases which don't add anything new to TypeScript syntax. It would be the same thing as NonNullable, Record, or Partial type aliases. And still if TypeScript has NonNullable type that is used in non-strict environment, why not have equivalent types for strict one?

[MartinJohns]

The thing I'd like to see are simple type aliases which don't add anything new to TypeScript syntax. It would be the same thing as NonNullable, Record, or Partial type aliases. And still if TypeScript has NonNullable type that is used in non-strict environment, why not have equivalent types for strict one?

See #39522 (comment):

We've opted to not include utility type aliases in the lib unless they're required for declaration emit purposes.

[fatcerberus]

It’s not exactly the same, but the same concerns apply, namely that people will argue endlessly over whether Nullable<T> should be T | null, T | undefined, or T | null | undefined and each side will insist theirs is the “right” way. Better to just be explicit about which one you want than to force the language to commit to one canonical definition of “nullable” when none of the options is clearly better than the others.

[lkster]

It’s not exactly the same, but the same concerns apply, namely that people will argue endlessly over whether Nullable<T> should be T | null, T | undefined, or T | null | undefined and each side will insist theirs is the “right” way. Better to just be explicit about which one you want than to force the language to commit to one canonical definition of “nullable” when none of the options is clearly better than the others.

Yes, I'm aware of that, hence I've proposed two separated type aliases and optional third which would be a compound. Anyway sure, it's more clear now. Also @MartinJohns's addition expleinaed some cases so I understand you guys had endless debates about that and decided you'll go this way. I'll close that as not planned. Thanks for answers!