Repository: TypeScript
Issue: Literal Comparison for Conditional Types
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->
`compare type to value literal`, `conditional type literals`, `type is literal`, `complex schemas`
## Suggestion
The ability to compare a type against an example of that type, for use in complex type aliases and interfaces.
<!-- A summary of what you'd like to see added or changed -->

## Use Cases
When designing a complex schema for an object, the actual fields contained by the object can branch in many different ways.

Of course, it's possible to approach the problem by using nullable types for fields that are not present in all cases. This results in a readable type in the error inspection window, but lots of unnecessarily defensive code that would have been solved by a fully typed schema.

It's also possible to create a discriminated union consisting of every branch--but what if you have a lot of branches? It becomes undesirably repetitive and the error inspection window is a wall of text.

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples
Take for example, the type of a Pipeline:
```TypeScript
type Action = 'Data Selection' | 'Data Cleanup' | 'Train' | 'Store' | 'Deploy'
type Status = 'running' | 'finished' | 'error'
type PipelineStep = {
	name: Action
	status: Status
	tags: Array<string>
        // `never` actually always results in a type check error right now
	message: PipelineStep['status'] is 'Error' ? string : never 
	path: PipelineStep['name'] is 'Data Selection' | 'Store' ? string : never
	trainingID: PipelineStep['name'] is 'Train' ? string : never
	endpoint: PipelineStep['name'] is 'Deploy' ? string : never
} 
```
Contrasted with the current syntax and discriminated unions:
```TypeScript
type PipelineStep = {
	name: Action
	status: Exclude<Status, 'Error'>
	tags: Array<String>
} | {
	name: Action
	status: 'Error'
	tags: Array<string>
	message: string
} | // I give up
```
The number of branches is multiplicative in nature. In this case, the most complex schema could have a maximum of 6 (Actions) x 3 (Status) possible branches.
After optimization, it becomes:
```TypeScript
type StepStatus = {
	status: Exclude<Status, 'Error'>
} | {
	status: 'Error'
	message: string
}

type DataSelectionStep = {
	name: 'Data Selection'
	path: string
}
type TrainingStep = { 
	name: 'Training'
	trainingID: string
}
type StoreStep = {
	name: 'Store'
	path: string
}
type DeployStep = { 
	name: 'Deploy'
	endpoint: string
}

type PipelineStep = (DataSelectionStep | TrainingStep | StoreStep | DeployStep | {
	name: Exclude<Action, 'Training' | 'Data Selection' | 'Store' | 'Deploy'>
}) & StepStatus & {
	tags: Array<String>
}
```
which isn't really much better...
<!-- Show how this would be used and what the behavior would be -->

## Checklist

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, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).