Skip to content

Commit

Permalink
Created No New Utility Types (markdown)
Browse files Browse the repository at this point in the history
  • Loading branch information
RyanCavanaugh committed Nov 1, 2023
1 parent 968a685 commit 9833c3e
Showing 1 changed file with 14 additions and 0 deletions.
14 changes: 14 additions & 0 deletions No-New-Utility-Types.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
We do not add new "utility" types to the standard library.

The existing global utility types you see (`Omit`, `Pick`, etc) are either required for declaration emit, or were written before this rule was put into place.

The primary reason for this is that, for a given type, we need to:
* Define its overall desired behavior
* Pick a name that doesn't conflict with anything likely to be in userspace, but is still descriptive
* Decide if they are distributive or not distributive
* Decide if they should be strongly or weakly defined in terms of their constraints
* Make many other type-specific decisions

Reasonable people can disagree about any of these points, much as they do about other design decisions. For example, [the typing of `Array#includes` is "stricter" than some people would like](https://github.com/microsoft/TypeScript/issues/26255), whereas `Omit` is not [considered "strict enough" by some people](https://github.com/microsoft/TypeScript/issues/30825). Any time we've introduced a utility type, it's spurred these disatisfications where people feel that TypeScript obviously didn't just pick the "correct" definition, even though the definition we added matched someone else's "correct" definition. And even if we change our minds and agree about which definition *should* have been used, it's too much of a breaking change to modify these types at all once they're in common use.

Since there's no *need* for these utility types, and people rightfully are annoyed that any definition we pick will effectively prevent anyone else from using those names (due to confusion), our current stance is that it's better to leave utility type definition up to users so that they can pick the definitions that best match their individual desired semantics, rather than introducing a new global type that almost will certainly raise justifiable ire among a nontrivial set of users.

0 comments on commit 9833c3e

Please sign in to comment.