Add `Optional` type

[EladBezalel]

An optional type is really missing in the context of return types,
When a function might a value or not you find yourself piping undefined

type Maybe<T> = T | undefined;

Can be really useful

[BendingBender]

@EladBezalel What about null?
@sindresorhus Too trivial?

[EladBezalel]

I'd make a separate type Nullable<T>

[BendingBender]

Sorry about this but when I think about a Maybe type I have usually something in mind that resembles the functional variant of it, also called Optional.

Any ideas for a less overloaded name?

[BendingBender]

And just looking at the type, it is so trivial that it actually sacrifices readability in favor of saving a few keystrokes. Now, everyone reading this has to look it up instead of directly and unambiguosly understand it.

This is a clear NAK from my side. @sindresorhus has the final word on it.

[EladBezalel]

As far as i see it it's very self explanatory, once you find out that type you understand it and use it.

As for the naming i wanted something that implies - you either get T or get nothing
That's why i thought Maybe T is really readable

[sindresorhus]

If we were to add it, I would call it Optional and the nil case would be undefined, not null.

I've been wanting this type since I started using TypeScript. I also initially found it surprising that type Foo = number? didn't work. However, I agree with @BendingBender. The only way it makes sense is for it to be a built-in. Without, it's just a type that saves a few characters in favor decreased usability and readability. It's only useful if everyone uses the same naming and everyone knows what it means. That can only happen if it's a built-in type. Another thing that could happen if it was a built-in is syntax sugar like type Foo = number?.

I would strongly encourage you to open an issue on TypeScript about adding this type.

[JoBrad]

I use a Maybe as a result type for quite a few of my utility functions that are designed to return undefined if certain conditions aren't met. I usually define it as type Maybe<T> = NonNullable<T> | undefined to explicitly note that a null value is not an acceptable response.

It's all semantics, of course, but for result types I prefer Maybe, while using Optional for input values.

[sindresorhus]

I have reconsidered and I think we should add this. While I wouldn't recommend using it in reusable packages, and I think we should clearly discourage it for open source projects, it can be a nice utility for large internal projects where everyone knows what it means. It would also be nice to have it here as an example on how to implement it correctly. And it can be a good way to push TypeScript to add it if more people are exposed to its usefulness and start using it in their code.

I think we should go for:

type Optional<T> = NonNullable<T> | undefined;

Alternatively: (Which inlines NonNullable without the undefined exclusion)

type Optional<T> = T extends null ? never : (T | undefined);

Opinions on which? I'm leaning towards the latter.

---

If you wanna do a PR for this, please read https://github.com/sindresorhus/type-fest/blob/master/.github/contributing.md thoroughly and look at previous PR additions.

[CarsonF]

FWIW I like

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

Which is just the exact opposite of NonNullable.

I typically don't mind having the type as null or undefined because those are usually handled the same way. My use case is this:

const upper = (str: Nullable<string>) => str ? str.toUpperCase() : null;
interface Obj {
  foo?: string;
  bar: string | null;
}
const obj: Obj;
upper(obj.foo);
upper(obj.bar);

[sindresorhus]

@CarsonF Including null is not going to happen for reasons outlined here.

[CarsonF]

Thanks for the link. I know what I'll be thinking about the rest of the day 😉