Conditional type simplifications & Globally cached conditional type instances #29437

weswigham · 2019-01-16T01:15:31Z

Conditional types of the form T extends U ? T : never simplify to T & U if T always extends U, and never if T can never extend U.

Conditional types of the form T extends U ? never : T simplify to T (T & not U to be more precise, once those are available) if T never extends U, and never if T always extends U.

…nd fix restrictive instantiations

jack-williams · 2019-01-16T09:28:35Z

Does this mean Extract<number | string, any> ~~> any?

ahejlsberg · 2019-01-16T17:02:16Z

src/compiler/checker.ts

@@ -9982,6 +9982,26 @@ namespace ts {
            if (checkType === wildcardType || extendsType === wildcardType) {
                return wildcardType;
            }
+            // Simplifications for types of the form `T extends U ? U : never` and `T extends U ? never : T`.


First form should be T extends U ? T : never.

ahejlsberg · 2019-01-16T17:06:34Z

src/compiler/checker.ts

+            // Simplifications for types of the form `T extends U ? U : never` and `T extends U ? never : T`.
+            const originalCheckType = getActualTypeVariable(root.checkType);
+            const trueType = instantiateType(root.trueType, mapper);
+            const falseType = instantiateType(root.falseType, mapper);


These instantiations were always deferred before. Now they're eager. I'm somewhat concerned this creates extra work that we don't need to do.

I could defer them to only when simplified again, but then only types with a declared never would be simplifiable, whereas like this one branch can be instantiated to never, allowing a broader set of conditional types to be reduced.

ahejlsberg · 2019-01-16T17:12:10Z

src/compiler/checker.ts

+                if (isTypeAssignableTo(getRestrictiveInstantiation(checkType), getRestrictiveInstantiation(extendsType))) { // Always true
+                    return getIntersectionType([trueType, extendsType]);
+                }
+                else if (getUnionType([getIntersectionType([checkType, extendsType]), neverType]).flags & TypeFlags.Never) { // Always false


Shouldn't this check the permissive form of the check and extends types? I'm not really following the logic here.

So, the permissive form check returns true for X extends never, while this version of the check does not. We want to ignore the never extends never case here, since that will become a never result in both branches anyway (meaning we'd like x extends never or x extends something instantiable to never to simplify even when the permissive instantiation says there's technically one instantiatiom which'd give another result).

With negated types in place, I'd probably write the check as isTypeAssignableTo(checkType, getNegatedType(extendsType)) instead, but without that in place, this accomplishes the same thing when only normal types exist.

weswigham · 2019-01-16T18:15:08Z

Does this mean Extract<number | string, any> ~~> any?

Yeah - number | string extends any is trivially true, then we produce (number | string) & any which just becomes any. Specifically in the extends any case we maybe want to avoid making the intersection to avoid deleting information? We do this when calculating conditional constraints internally already and they should probably match (this is just a simplification to the true branch constraint, after all) - I'll actually go extract the logic and reuse it.

…ication

weswigham · 2019-01-16T18:36:24Z

I'll actually go extract the logic and reuse it.

Done~ extends any (and now things that instantiate to any) no longer create any's in conditional type true branches (so they behave more like the unknown they're acting as).

weswigham · 2019-01-24T21:31:44Z

@ahejlsberg I've run this on user, RWC, and DT suites - there's no visible adverse effects. I think this is solid.

RyanCavanaugh · 2019-01-25T19:24:57Z

Split the bugfix part into a separate PR for 3.3 👍

RyanCavanaugh · 2019-01-25T19:25:18Z

And rename a thing

fatcerberus · 2019-01-28T16:22:00Z

(number | string) & any which just becomes any

...wait, why? Intuitively I expect that to simplify to number | string. any is a really strange type isn’t it...

jack-williams · 2019-01-28T19:01:18Z

@fatcerberus It is best not to think of any as a type, but a set of types, IMO. I think current literature would have (number | string) & any be irreducible (up to union-intersection distribution), but TypeScript predates that, and also has practical considerations. Reducing to any is probably the most sensible and conservative choice.

weswigham · 2019-03-02T00:44:21Z

@typescript-bot test this & @typescript-bot run dt

typescript-bot · 2019-03-02T00:44:24Z

Heya @weswigham, I've started to run the Definitely Typed test suite on this PR at 47fbc47. You can monitor the build here. It should now contribute to this PR's status checks.

typescript-bot · 2019-03-02T00:44:24Z

Heya @weswigham, I've started to run the extended test suite on this PR at 47fbc47. You can monitor the build here. It should now contribute to this PR's status checks.

…`any` and restrictive type parameters

weswigham · 2019-03-07T23:13:57Z

@typescript-bot run dt - I just made some changes after running into a manifestation of #30152 with the new simplifications on DT and included a small workaround.

typescript-bot · 2019-03-07T23:13:59Z

Heya @weswigham, I've started to run the Definitely Typed test suite on this PR at 8268eeb. You can monitor the build here. It should now contribute to this PR's status checks.

weswigham · 2019-03-08T01:01:44Z

Sweet, the only change on DT is now a NodePath<Identifier> -> NodePath<{ type: "Identifier"; } & Identifier> in babel's types inline with the baseline changes in this PR (which if supertype reduction was a thing would be a noop), so DT looks super clean now.

@ahejlsberg can we look at merging this again? #28748 is a pretty popular issue to fix and the global caching of conditionals should be a nice perf win.

ahejlsberg

Add a getConditionalTypeWorker that doesn't have to worry about caching.

weswigham · 2019-03-08T22:23:09Z

@ahejlsberg done.

jcalz · 2019-03-22T02:26:47Z

It's too bad that intersections of known concrete object types don't reduce to their mapped identity type automatically (e.g., {a: string} & {b: number} is not automatically collapsed to {a: string, b: number}), since this new behavior is going to take Extract<T, U> and turn it from a simple filtering of a union into a gnarly union-of-intersections. I suppose one could get back something that looks like the old behavior via

type OldExtract<T, U> = T extends U ? { [K in keyof T]: T[K] } : never

maybe?

I'm also not sure how T & U is simpler than T if T extends U is known to be true. If T extends U then T & U should be equivalent to T (except that the compiler probably won't notice it and will end up carrying around these vestigial intersections). What am I missing? Can someone give me an example of a type where T extends U ? true : false is true but T & U is not just a more complicated way of expressing T?

Jessidhia · 2019-03-22T02:32:49Z

{} extends { a?: boolean } ? true : false is true, but {} & { a?: boolean } is not the same as just {}

(this is not a full answer, just a counter-example)

jcalz · 2019-03-22T02:40:25Z

Yeah, I'll buy that... optional properties are weird. (The value {a: 1} is assignable to type {} but not to type {a?: boolean}, so it's odd that {} extends {a?: boolean} is seen as true.)

weswigham added 2 commits January 15, 2019 16:52

Introduce simpliciations for extract/exclude-like conditional types a…

66ea5a0

…nd fix restrictive instantiations

Add test for the common simplifications

d3c02d1

weswigham requested review from ahejlsberg and RyanCavanaugh January 16, 2019 01:15

ahejlsberg reviewed Jan 16, 2019

View reviewed changes

unify true branch constraint generation logic and true branch simplif…

5dc6789

…ication

weswigham added 5 commits January 16, 2019 11:04

Use identical check on instantiated types

ad4b7b2

Add late-instantiate conditionals to test

ca5530c

Globally cache conditional type instantiations ala indexed access types

983dd77

Handle any simplifications

c159aaa

Merge branch 'master' into conditional-type-simpliciations

73c9445

RyanCavanaugh assigned weswigham Jan 24, 2019

DanielRosenwasser mentioned this pull request Jan 25, 2019

Design Meeting Notes, 1/25/2019 #29588

Closed

weswigham mentioned this pull request Jan 25, 2019

Fixup restrictive instantiations to actually erase type parameter constraints #29592

Merged

Merge branch 'master' into conditional-type-simpliciations

432b143

weswigham changed the title ~~Conditional type simplifications & Restrictive Instantiation Fix~~ Conditional type simplifications & Globally cached conditional type instances Jan 31, 2019

This was referenced Feb 1, 2019

Conditional Types: Type parameters with unknown constraint are not the most restrictive type when relating from any. #29674

Closed

Negated types #29317

Closed

weswigham mentioned this pull request Feb 13, 2019

Use built local on CI and not LKG #29886

Merged

weswigham added 3 commits February 20, 2019 10:15

Merge branch 'master' into conditional-type-simpliciations

2090582

Factor empty intersection check into function

d60667e

Merge branch 'master' into conditional-type-simpliciations

47fbc47

weswigham added 4 commits March 7, 2019 10:12

Merge branch 'master' into conditional-type-simpliciations

3da72eb

Modifify conditional type constraints to better handle single-branch …

917b904

…`any` and restrictive type parameters

Add test case motivating prior commit

dd36e01

Fix lint

8268eeb

ahejlsberg requested changes Mar 8, 2019

View reviewed changes

Factor logic into worker vs cacheing function

5896af3

Remove now unneeded casts

80bceda

weswigham merged commit a9ad94a into microsoft:master Mar 8, 2019

weswigham deleted the conditional-type-simpliciations branch March 8, 2019 23:33

jack-williams mentioned this pull request Mar 9, 2019

Uniform Generics for Conditional Type Inference and Type Parameter Narrowing [Experiment] #30284

Closed

jack-williams mentioned this pull request Mar 19, 2019

3.4.0-rc - behaviour changed from 3.3 (regression?) #30489

Closed

dragomirtitian mentioned this pull request Mar 24, 2019

Possible regression in 3.4 with distributive conditional types #30569

Closed

OliverJAsh mentioned this pull request Apr 1, 2019

Unexpected error when using generic with Pick and Exclude #28748

Closed

RyanCavanaugh mentioned this pull request Apr 8, 2019

~50x regression in type instantiation count between 3.3 and 3.4 #30819

Closed

jcalz mentioned this pull request May 9, 2019

Mapped conditional type leaks unbound type parameter #31326

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Conditional type simplifications & Globally cached conditional type instances #29437

Conditional type simplifications & Globally cached conditional type instances #29437

weswigham commented Jan 16, 2019 •

edited

Loading

jack-williams commented Jan 16, 2019

ahejlsberg Jan 16, 2019

ahejlsberg Jan 16, 2019

weswigham Jan 16, 2019 •

edited

Loading

ahejlsberg Jan 16, 2019

weswigham Jan 16, 2019 •

edited

Loading

weswigham commented Jan 16, 2019 •

edited

Loading

weswigham commented Jan 16, 2019

weswigham commented Jan 24, 2019

RyanCavanaugh commented Jan 25, 2019

RyanCavanaugh commented Jan 25, 2019

fatcerberus commented Jan 28, 2019

jack-williams commented Jan 28, 2019 •

edited

Loading

weswigham commented Mar 2, 2019

typescript-bot commented Mar 2, 2019 •

edited

Loading

typescript-bot commented Mar 2, 2019 •

edited

Loading

weswigham commented Mar 7, 2019

typescript-bot commented Mar 7, 2019 •

edited

Loading

weswigham commented Mar 8, 2019

ahejlsberg left a comment

weswigham commented Mar 8, 2019

jcalz commented Mar 22, 2019 •

edited

Loading

Jessidhia commented Mar 22, 2019 •

edited

Loading

jcalz commented Mar 22, 2019

Conditional type simplifications & Globally cached conditional type instances #29437

Conditional type simplifications & Globally cached conditional type instances #29437

Conversation

weswigham commented Jan 16, 2019 • edited Loading

jack-williams commented Jan 16, 2019

ahejlsberg Jan 16, 2019

Choose a reason for hiding this comment

ahejlsberg Jan 16, 2019

Choose a reason for hiding this comment

weswigham Jan 16, 2019 • edited Loading

Choose a reason for hiding this comment

ahejlsberg Jan 16, 2019

Choose a reason for hiding this comment

weswigham Jan 16, 2019 • edited Loading

Choose a reason for hiding this comment

weswigham commented Jan 16, 2019 • edited Loading

weswigham commented Jan 16, 2019

weswigham commented Jan 24, 2019

RyanCavanaugh commented Jan 25, 2019

RyanCavanaugh commented Jan 25, 2019

fatcerberus commented Jan 28, 2019

jack-williams commented Jan 28, 2019 • edited Loading

weswigham commented Mar 2, 2019

typescript-bot commented Mar 2, 2019 • edited Loading

typescript-bot commented Mar 2, 2019 • edited Loading

weswigham commented Mar 7, 2019

typescript-bot commented Mar 7, 2019 • edited Loading

weswigham commented Mar 8, 2019

ahejlsberg left a comment

Choose a reason for hiding this comment

weswigham commented Mar 8, 2019

jcalz commented Mar 22, 2019 • edited Loading

Jessidhia commented Mar 22, 2019 • edited Loading

jcalz commented Mar 22, 2019

weswigham commented Jan 16, 2019 •

edited

Loading

weswigham Jan 16, 2019 •

edited

Loading

weswigham Jan 16, 2019 •

edited

Loading

weswigham commented Jan 16, 2019 •

edited

Loading

jack-williams commented Jan 28, 2019 •

edited

Loading

typescript-bot commented Mar 2, 2019 •

edited

Loading

typescript-bot commented Mar 2, 2019 •

edited

Loading

typescript-bot commented Mar 7, 2019 •

edited

Loading

jcalz commented Mar 22, 2019 •

edited

Loading

Jessidhia commented Mar 22, 2019 •

edited

Loading