Repository: TypeScript
Issue: Optional Type Chaining
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->
<!--
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
-->
optional type chaining syntax

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->
Support [optional chaining](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#optional-chaining) syntax for types

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

The following pattern is so common that optional chaining syntax was introduced into JS:
```typescript
type DeeplyNullableObject = undefined | {
  key?: {
    nestedKey?: {
      deeplyNestedKey?: 'value'
    }
  }
}

const deeplyNullableObject: DeeplyNullableObject = {}

// cumbersome
deeplyNullableObject
  ? deeplyNullableObject['key']
    ? deeplyNullableObject['key']['nestedKey']
      ? deeplyNullableObject['key']['nestedKey']['deeplyNestedKey']
      : undefined
    : undefined
  : undefined

// convenient!
deeplyNullableObject?.['key']?.['nestedKey']?.['deeplyNestedKey']
```

However, in TypeScript, accessing `deeplyNullableObject?.key?.nestedKey?.deeplyNestedKey`'s type is still cumbersome (even with [TypeScript's super helpful `NonNullable` utility type](https://www.typescriptlang.org/docs/handbook/utility-types.html#nonnullabletype)):
```typescript
// cumbersome
type DeeplyNestedValue = NonNullable<
  NonNullable<
    NonNullable<
      DeeplyNullableObject
    >['key']
  >['nestedKey']
>['deeplyNestedKey']
```

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

Supporting optional chaining syntax for types would make working with these types just as easy as it is for their runtime counterparts:
```typescript
// convenient!
type DeeplyNestedValue = DeeplyNullableObject?.['key']?.['nestedKey']?.['deeplyNestedKey']
```

It also allows developers to easily convert some runtime values declared using optional chaining to types by simply applying `typeof`, which is always satisfying and feels well within the spirit of TypeScript being elegantly consistent with JavaScript:
```typescript
type DeeplyNestedValue = typeof deeplyNullableObject?.['key']?.['nestedKey']?.['deeplyNestedKey']
```