Add 'extends' clause to 'infer' type #48112

rbuckton · 2022-03-03T23:53:32Z

This adds an optional extends clause to infer T to specify an explicit constraint for the T type parameter. When specified,
the explicit constraint overrides the constraint we would have attempted to infer for T.

For example, if you wished to infer a type from the first element of a tuple but also constrain that type, you might currently need to write something like the following:

// This type alias serves as an example of any type with a constraint you might need to satisfy
type MustBeNumber<T extends number> = { y: T };

// Option 1, use a nested conditional
type X1<T> =
  T extends [infer U] ?
    U extends number ? MustBeNumber<U> :
    never :
  never;

// Option 2, use a secondary type to constrain the inference
type Is<T extends U, U> = T;
type X2<T> =
  T extends [Is<infer U, number>] ? MustBeNumber<U> :
  never;

For Option 1, you are forced to create two conditional types, resulting in two alternatives. If you are testing multiple other conditions, this could result in an unmanageable branching structure which results in the need to define additional type aliases for repeated branches:

type X1<T> =
  T extends [infer U] ? U extends number ? MustBeNumber<U> : 
    T extends {x: infer U} ? U extends number ? MustBeNumber<U> :
      ...
  // repeats...
  T extends {x: infer U} ? U extends number ? MustBeNumber<U> :
    ...

For Option 2, you are required to define a second type to enforce the constraint. While this is trivial, it is unreliable when inferring to the same type variable in more than one position, as it is possible to define disjoint constraints:

type X2<T> = T extends [Is<infer U, number>, Is<infer U, string>] ? MustBeNumber<U> : never; // U will always be `never`

In contrast, specifying an explicit constraint via extends allows us to achieve the simpler branching structure of Option 2, while providing additional safety by checking that the constraints are consistent:

// simpler branching due to combining the constraint
type X3<T> = T extends [infer U extends number] ? MustBeNumber<U> : never;

// all constraints for same type parameter must match, if present
type X4<T> = T extends [infer U extends number, infer U extends number] ? MustBeNumber<U> : never;

// only one type parameter needs to be constrained (similar to class/interface merging)
type X5<T> = T extends [infer U extends number, infer U] ? MustBeNumber<U> : never;
type X6<T> = T extends [infer U, infer U extends number] ? MustBeNumber<U> : never;

// errors on inconsistent constraints
type X7<T> = T extends [infer U extends string, infer U extends number] ? U : never;
// error: All declarations of 'U' must have identical constraints.

Related #48094

RyanCavanaugh · 2022-03-04T00:41:10Z

Do we have a sense of what kind of libraries would benefit from this?

rbuckton · 2022-03-04T01:30:06Z

Probably anyone doing tuple type or template literal type manipulation, plus #48112. I regularly find myself needing to define something like Is or use Extract when inferring from tuple types when I need a more specific type than inference allows.

I found a few places that could leverage this:

type-fest
- https://cs.github.com/sindresorhus/type-fest/blob/cbd7ec510bd136ac045bbc74e391ee686b8a9a2f/source/get.d.ts?q=infer#L15-L19
- https://cs.github.com/sindresorhus/type-fest/blob/cbd7ec510bd136ac045bbc74e391ee686b8a9a2f/source/get.d.ts#L59-L66 (could be written to a form that's easier to read)
- https://cs.github.com/sindresorhus/type-fest/blob/cbd7ec510bd136ac045bbc74e391ee686b8a9a2f/source/join.d.ts?q=infer#L28-L29 (though there's possibly an inference bug that could be fixed here as well)
- https://cs.github.com/sindresorhus/type-fest/blob/cbd7ec510bd136ac045bbc74e391ee686b8a9a2f/source/delimiter-case.d.ts?q=infer#L8-L20 (explicit constraints would reduce the number of : never branches)
material-ui
- https://cs.github.com/mui/material-ui/blob/2a81d58c7b9e10718474639dc613078050e512b9/packages/mui-joy/src/styles/defaultTheme.ts?q=infer#L31-L39
redux-orm (on DefinitelyTyped)
- https://cs.github.com/DefinitelyTyped/DefinitelyTyped/blob/2280eb45b474bf8e92ff34b1d2775afc03cffc6f/types/redux-orm/db/Table.d.ts#L34-L46
- https://cs.github.com/DefinitelyTyped/DefinitelyTyped/blob/2280eb45b474bf8e92ff34b1d2775afc03cffc6f/types/redux-orm/Model.d.ts#L383-L389
react-router (on DefinitelyTyped)
- https://cs.github.com/DefinitelyTyped/DefinitelyTyped/blob/2280eb45b474bf8e92ff34b1d2775afc03cffc6f/types/react-router/index.d.ts?q=path%3A*.ts+%22infer%22#L157-L167 (could be simplified)
convict (on DefinitelyTyped)
- https://cs.github.com/DefinitelyTyped/DefinitelyTyped/blob/2280eb45b474bf8e92ff34b1d2775afc03cffc6f/types/convict/index.d.ts#L121-L129

phryneas · 2022-03-04T08:38:35Z

You can add the Redux ecosystem (Redux Toolkit, Reselect) to that list - we have a few cases where we have a
Something<X> extends infer Y ? Y extends Bar ? /* actual logic */.

I'm pretty sure @tannerlinsley will have quite a few uses in React Table for this, but that's speculation from my side.

tannerlinsley · 2022-03-04T14:38:01Z

I would greatly benefit from this in React Table and React Location where I am already writing a lot branching conditional types to both enforce and extract generics. It’s brittle. This would make those contracts easier to define and much more reliable.

DanielRosenwasser · 2022-03-04T18:40:38Z

@typescript-bot pack this

typescript-bot · 2022-03-04T18:40:42Z

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at bafe193. You can monitor the build here.

typescript-bot · 2022-03-04T19:05:51Z

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/121221/artifacts?artifactName=tgz&fileId=9A84662ABF9C9E378556EF91C66AB21BF7E1E2513A39ED6E4C61DFA8C11CBA6302&fileName=/typescript-4.7.0-insiders.20220304.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.7.0-pr-48112-6".;

rbuckton · 2022-03-07T20:28:19Z

In the design meeting we discussed the syntax ambiguity with infer T extends U ?. There are three approaches we can take:

Leave the precedence as written in this PR. This would be a breaking change since the following is perfectly legal TS today:
```
type X<T> = T extends (infer U extends number ? 1 : 0) ? 1 : 0;
```
If we choose this option, the above would become a parse error and existing code would need to change to parenthesize the infer U.
Use speculative parsing disambiguate infer T extends U ?. This means that we would speculatively parse the extends clause of an infer type, and if we encounter a ? we would rewind. This is similar to how we speculatively parse arrow functions, but has the same drawback: If the type in the extends clause is very large we would have to re-parse it again. This may be acceptable as infer T extends U ? doesn't seem to be a common occurrence in the wild, and if a project does encounter a slowdown due to the lookahead, they can easily wrap the infer type in parens to avoid rewinding.
Use a cover grammar to disambiguate infer T extends U ?. This means that we would parse the infer T extends U as an infer type, and if we encounter a ? following that type we would recreate the infer type without the constraint and reuse the node for the constraint. This avoids the performance implications of speculative parsing, but will require more thorough testing to ensure that it doesn't break incremental parsing scenarios.
Use a different keyword instead of extends for an infer type's constraint, such as of (i.e., infer T of U). This avoids the ambiguity, but introduces a second term with the same meaning as extends, which could be a source of confusion.

I investigated using something like JS's [In] parser context, however that approach didn't seem viable. The places we would want to allow extends in an infer type (such as in a parenthesized type) are the same places you might want to infer to the check type of a conditional type, so there was no way to separate them using a context flag.

rbuckton · 2022-03-07T20:32:45Z

You can add the Redux ecosystem (Redux Toolkit, Reselect) to that list - we have a few cases where we have a Something<X> extends infer Y ? Y extends Bar ? /* actual logic */.

[...]

I have been a bit wary of classifying all cases of ... infer Y ? Y extends Bar ? ... as possible use cases since Y extends Bar ? ... could also indicate the need to distribute over Y rather than merely constraining it. Switching to infer T extends U will definitely need to be assessed on a case-by-case basis.

phryneas · 2022-03-07T21:07:21Z

You can add the Redux ecosystem (Redux Toolkit, Reselect) to that list - we have a few cases where we have a Something<X> extends infer Y ? Y extends Bar ? /* actual logic */.
[...]

I have been a bit wary of classifying all cases of ... infer Y ? Y extends Bar ? ... as possible use cases since Y extends Bar ? ... could also indicate the need to distribute over Y rather than merely constraining it. Switching to infer T extends U will definitely need to be assessed on a case-by-case basis.

Of course, but we only really use it in cases where we have the else case be never - we only really add that inner extends to make the compiler happy. Might not be the core of this PR, but it definitely helps us write code.

RyanCavanaugh · 2022-03-08T22:37:17Z

I'd also toss in "require parenthesization" as a possible parsing strategy

type X<T> = T extends (infer U extends number) ? 1 : 0;

rbuckton · 2022-03-09T02:32:09Z

I'd also toss in "require parenthesization" as a possible parsing strategy
type X<T> = T extends (infer U extends number) ? 1 : 0;

Unfortunately, requiring parens alone doesn't resolve the ambiguity, since T extends (infer U extends number ? 1 : 0) ? 1 : 0 is already legal (and thus we could still encounter a trailing ?).

Right now I'm leaning towards (2) for its simplicity, but changing the noConditionalTypes parameter of parseTypeWorker into a parser context flag so that we can relax the need for parens in situations where we can be sure a trailing ? wouldn't be ambiguous:

// ok, parsed as conditional
type X1<T> = T extends ((infer U) extends number ? 1 : 0) ? 1 : 0; 

// ok, parsed as `infer..extends` (speculative parse succeeds due to no trailing `?`)
type X2<T> = T extends (infer U extends number) ? 1 : 0; 

// ok, parsed as `infer..extends` (conditional types not allowed in 'extends type' of conditional)
type X3<T> = T extends infer U extends number ? 1 : 0; 

// ok, parsed as `infer..extends` (precedence wouldn't have parsed the `?` as part of a type operator)
type X4<T> = T extends keyof infer U extends number ? 1 : 0; 

// ok, parsed as conditional (speculative parse rewinds when it sees the first `?`)
type X5<T> = T extends { [P in infer U extends keyof T ? 1 : 0]: 1; } ? 1 : 0; 

// ok, parsed as `infer..extends` (no trailing `?`)
type X6<T> = T extends { [P in infer U extends keyof T]: 1; } ? 1 : 0; 

// ok, parsed as conditional (speculative parse rewinds when it sees the first `?`)
type X7<T> = T extends { [P in keyof T as infer U extends P ? 1 : 0]: 1; } ? 1 : 0; 

// ok, parsed as `infer..extends` (speculative parse succeeds due to no trailing `?`)
type X8<T> = T extends { [P in keyof T as infer U extends P]: 1; } ? 1 : 0;

It doesn't work quite the same way as [In], since this still requires speculative parsing, but its reliable and consistent and isn't a breaking change.

treybrisbane · 2022-03-09T07:51:51Z

I'm gonna go ahead and ask the dumb question: Why can't we automatically derive the constraint of an inferred type binding from the constraint of the type being matched?

For example, given

type Quote<AString extends string> = `"${AString}"`;

type QuotedFirstElement<AStringTuple extends readonly string[]> =
  AStringTuple extends readonly [infer FirstElement, ...infer Rest]
    ? Quote<FirstElement> // Currently errors here, because `FirstElement` is only constrained to `unknown`
    : never;

why can't we say "well, since AStringTuple has a constraint of readonly string[], any elements we infer from it should therefore have a constraint of string"?

Intuitively, I suspect there's a very good reason for this and that I just haven't thought it through enough, but someone's gotta spring the trap! 😁

rbuckton · 2022-03-09T19:14:51Z

I'm gonna go ahead and ask the dumb question: Why can't we automatically derive the constraint of an inferred type binding from the constraint of the type being matched?

We do have automatic inference, and there are ways we can improve it. However, that still wouldn't solve the issue at hand. There are times where you need a more-specific type than what the inferred constraint might allow:

type X<T extends any[]> =
  T extends [infer U extends string, ...infer R] ? ... :
  T extends [infer U extends number, ...infer R] ? ... :
  ...;

Above, I might want to make branching decisions based on a more specific constraint. This also ties into #48094, which uses more specific inferences for infer in a template literal type to pull out numeric literals.

rbuckton · 2022-03-11T19:47:46Z

This last change modifies the parse based on #48112 (comment).

I wanted to ensure that parenthesization was accurate, so I took a pass through the parenthesizer rule logic for types to be more accurate. One side-effect of that is that we'll emit fewer parens in declarations and diagnostics. Where we might have previously written (A & B) | (C & D), we may now write A & B | C & D. The parens weren't strictly necessary, but they may have made the diagnostics more readable. I can make union/intersection parenthesization more aggressive in general, if necessary, or possibly just pass a more aggressive parenthesizer to the printer for typeToString if we only want it for diagnostics/quickinfo.

@DanielRosenwasser, can you provide your thoughts on the change in diagnostics evidenced here: 38eb412?show-viewed-files=true&file-filters%5B%5D=#diff-daa0fded8957f3b2eecdd68e6f89377663f965eb6e9c2b83f36955200b6e858fL5-R6

rbuckton · 2022-03-11T23:44:58Z

@typescript-bot perf test
@typescript-bot run dt
@typescript-bot test this
@typescript-bot user test this

typescript-bot · 2022-03-11T23:45:22Z

Heya @rbuckton, I've started to run the extended test suite on this PR at 2fb093c. You can monitor the build here.

typescript-bot · 2022-03-11T23:45:22Z

Heya @rbuckton, I've started to run the parallelized Definitely Typed test suite on this PR at 2fb093c. You can monitor the build here.

typescript-bot · 2022-03-15T21:57:32Z

Heya @rbuckton, I've started to run the parallelized Definitely Typed test suite on this PR at 326389b. You can monitor the build here.

…xtends'

rbuckton · 2022-03-22T00:07:53Z

Ping @ahejlsberg, @weswigham, @sandersn, @RyanCavanaugh

sandersn

The parser changes look good but I can't adequately comment on the checker changes.

weswigham

typeToTypeNodeHelper in the checker needs to include the constraint in the context.inferTypeParameters case of type.flags & TypeFlags.TypeParameter. If it's not there, we'll elide the constraints in error messages and inferred type declaration emit (eg, if one of these is inlined into a function return type).

Other than that, looks good - pretty simple.

rbuckton · 2022-03-24T04:05:05Z

typeToTypeNodeHelper in the checker needs to include the constraint in the context.inferTypeParameters case of type.flags & TypeFlags.TypeParameter. If it's not there, we'll elide the constraints in error messages and inferred type declaration emit (eg, if one of these is inlined into a function return type).

I think the latest change should cover this. I reuse getInferredTypeParameterConstraint, and elide the extends clause if the constraint is something we would have inferred from the surrounding context. Constraints inferred from a type argument to a type reference are preserved since the type reference may have been elided during typeToTypeNode.

typescript-bot assigned rbuckton Mar 3, 2022

typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Mar 3, 2022

rbuckton requested review from ahejlsberg and weswigham March 3, 2022 23:53

rbuckton mentioned this pull request Mar 3, 2022

More specific inference for constrained 'infer' types in template literal types #48094

Merged

rbuckton force-pushed the inferTypeExtends branch from 695e440 to bafe193 Compare March 4, 2022 18:31

DanielRosenwasser mentioned this pull request Mar 10, 2022

Design Meeting Notes, 3/4/2022 #48208

Closed

Add 'extends' clause to 'infer' type

8fd5eda

rbuckton force-pushed the inferTypeExtends branch from 38eb412 to 2fb093c Compare March 11, 2022 23:44

rbuckton added 2 commits March 15, 2022 17:50

tests 'infer' constraint using outer type parameter

4a7019e

Adds a test showing 'infer' cannot reference other 'infer' in same 'e…

02fa9c7

…xtends'

rbuckton requested review from sandersn and RyanCavanaugh March 18, 2022 23:41

rbuckton mentioned this pull request Mar 18, 2022

Updated to support 'infer..extends' microsoft/TypeScript-TmLanguage#902

Merged

Merge branch 'main' into inferTypeExtends

0aded71

sandersn approved these changes Mar 23, 2022

View reviewed changes

weswigham requested changes Mar 23, 2022

View reviewed changes

Emit extends clause for synthetic infer typesduring declaration emit

01b9a2d

rbuckton force-pushed the inferTypeExtends branch from 2e4fa4f to 01b9a2d Compare March 24, 2022 04:42

weswigham approved these changes Mar 24, 2022

View reviewed changes

RyanCavanaugh mentioned this pull request Mar 28, 2022

Source provides no match for required element at position 0 in target despite source extending [any, ...any[]] #48401

Closed

raghavthind2005 approved these changes Apr 1, 2022

View reviewed changes

rbuckton mentioned this pull request Apr 4, 2022

Extract to typedef from (invalid) type with comments in JS file causes assertion failure #48540

Closed

rbuckton merged commit 7da80d7 into main Apr 5, 2022

rbuckton deleted the inferTypeExtends branch April 5, 2022 19:35

g-plane mentioned this pull request Apr 13, 2022

feat(es/parser): Support 'extends' clause to 'infer' type swc-project/swc#4326

Merged

DanielRosenwasser mentioned this pull request Apr 13, 2022

Design Meeting Notes, 3/23/2022 #48684

Closed

artysidorenko mentioned this pull request Apr 22, 2022

fix: type issue when void or undefined is returned from query function TanStack/query#3541

Merged

JLHwung mentioned this pull request Apr 22, 2022

[ts 4.7] Support extends constraints for infer babel/babel#14476

Merged

Andarist mentioned this pull request Apr 25, 2022

Add tests case for function check type being correctly paranthesized in quick info #48836

Merged

yudai-nkt mentioned this pull request Apr 29, 2022

Allowing infer after extends T in conditional types would simplify complicated type definitions massively #47330

Closed

5 tasks

DanielRosenwasser mentioned this pull request May 4, 2022

Typescript Quick Info Formatter Removes parentheses () from declared type on hovering, for conditionally inferring types #48729

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add 'extends' clause to 'infer' type #48112

Add 'extends' clause to 'infer' type #48112

rbuckton commented Mar 3, 2022

RyanCavanaugh commented Mar 4, 2022

rbuckton commented Mar 4, 2022

phryneas commented Mar 4, 2022

tannerlinsley commented Mar 4, 2022

DanielRosenwasser commented Mar 4, 2022

typescript-bot commented Mar 4, 2022 •

edited

Loading

typescript-bot commented Mar 4, 2022 •

edited

Loading

rbuckton commented Mar 7, 2022 •

edited

Loading

rbuckton commented Mar 7, 2022 •

edited

Loading

phryneas commented Mar 7, 2022

RyanCavanaugh commented Mar 8, 2022

rbuckton commented Mar 9, 2022 •

edited

Loading

treybrisbane commented Mar 9, 2022

rbuckton commented Mar 9, 2022 •

edited

Loading

rbuckton commented Mar 11, 2022

rbuckton commented Mar 11, 2022

typescript-bot commented Mar 11, 2022 •

edited

Loading

typescript-bot commented Mar 11, 2022 •

edited

Loading

typescript-bot commented Mar 15, 2022 •

edited

Loading

rbuckton commented Mar 22, 2022

sandersn left a comment

weswigham left a comment •

edited

Loading

rbuckton commented Mar 24, 2022 •

edited

Loading

Add 'extends' clause to 'infer' type #48112

Add 'extends' clause to 'infer' type #48112

Conversation

rbuckton commented Mar 3, 2022

RyanCavanaugh commented Mar 4, 2022

rbuckton commented Mar 4, 2022

phryneas commented Mar 4, 2022

tannerlinsley commented Mar 4, 2022

DanielRosenwasser commented Mar 4, 2022

typescript-bot commented Mar 4, 2022 • edited Loading

typescript-bot commented Mar 4, 2022 • edited Loading

rbuckton commented Mar 7, 2022 • edited Loading

rbuckton commented Mar 7, 2022 • edited Loading

phryneas commented Mar 7, 2022

RyanCavanaugh commented Mar 8, 2022

rbuckton commented Mar 9, 2022 • edited Loading

treybrisbane commented Mar 9, 2022

rbuckton commented Mar 9, 2022 • edited Loading

rbuckton commented Mar 11, 2022

rbuckton commented Mar 11, 2022

typescript-bot commented Mar 11, 2022 • edited Loading

typescript-bot commented Mar 11, 2022 • edited Loading

typescript-bot commented Mar 15, 2022 • edited Loading

rbuckton commented Mar 22, 2022

sandersn left a comment

Choose a reason for hiding this comment

weswigham left a comment • edited Loading

Choose a reason for hiding this comment

rbuckton commented Mar 24, 2022 • edited Loading

typescript-bot commented Mar 4, 2022 •

edited

Loading

typescript-bot commented Mar 4, 2022 •

edited

Loading

rbuckton commented Mar 7, 2022 •

edited

Loading

rbuckton commented Mar 7, 2022 •

edited

Loading

rbuckton commented Mar 9, 2022 •

edited

Loading

rbuckton commented Mar 9, 2022 •

edited

Loading

typescript-bot commented Mar 11, 2022 •

edited

Loading

typescript-bot commented Mar 11, 2022 •

edited

Loading

typescript-bot commented Mar 15, 2022 •

edited

Loading

weswigham left a comment •

edited

Loading

rbuckton commented Mar 24, 2022 •

edited

Loading