You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per the docs on conditional types, deferred conditionals are expected to be resolved once sufficient context is provided (e.g. at a call-site) such that the compiler can evaluate a single branch of the conditional.
It appears that when the conditional type is in the value position of a mapped type, this does not occur.
🔎 Search Terms
deferred conditional types, mapped types
🕗 Version & Regression Information
This is the behavior in every version I tried (all versions on playground), and I reviewed the entire FAQ
Note that the assignments of leftOk and rightOk properly evaluate the conditional type to the branches dictated by the respective arguments passed to ok, with leftOk taking type {lr: string} and rightOk taking type {lr: number}.
However with the same information available (same exact arguments, just passed through one extra layer of call-stack, and a mapped type), leftOrphaned and rightOrphaned do not evaluate the conditional type, both remaining at type {lr: LR<F, string, number>} despite F being determined by the respective arguments passed to orphaned.
🙂 Expected behavior
The types of leftOrphaned and rightOrphaned should match the types of leftOk and rightOk respectively. Application of a type argument to a type parameter (in this case "left" or "right" to F) should apply to sub-expressions in a function body, and those applications should hold under a mapped type.
The text was updated successfully, but these errors were encountered:
Glad to see your response, thanks. @RyanCavanaugh got any pointers where I might look to familiarize myself if I wanted to take a crack at this particular issue?
Without knowing the root cause yet, I would still say this is very, very likely to require expertise beyond what we're capable of documenting. Probably there's a type mapper that needs to get passed around somewhere and that's not happening, but I could be way off.
Thanks very much @weswigham for the quick turnaround on resolution. @RyanCavanaugh I wonder if per your processes this means the fix might make it in sooner, or is the milestone assignment an imposed constraint on timeline? Anything I can do to help see this fix merged and released as soon as it could be?
If the PR gets merged before the 4.2 RC date (seems likely), it'll be in 4.2. For a long-standing issue with only one report, we wouldn't apply any extra prioritization effort beyond that.
Bug Report
Per the docs on conditional types, deferred conditionals are expected to be resolved once sufficient context is provided (e.g. at a call-site) such that the compiler can evaluate a single branch of the conditional.
It appears that when the conditional type is in the value position of a mapped type, this does not occur.
🔎 Search Terms
deferred conditional types, mapped types
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
Note that the assignments of
leftOk
andrightOk
properly evaluate the conditional type to the branches dictated by the respective arguments passed took
, withleftOk
taking type{lr: string}
andrightOk
taking type{lr: number}
.However with the same information available (same exact arguments, just passed through one extra layer of call-stack, and a mapped type),
leftOrphaned
andrightOrphaned
do not evaluate the conditional type, both remaining at type{lr: LR<F, string, number>}
despiteF
being determined by the respective arguments passed toorphaned
.🙂 Expected behavior
The types of
leftOrphaned
andrightOrphaned
should match the types ofleftOk
andrightOk
respectively. Application of a type argument to a type parameter (in this case "left" or "right" toF
) should apply to sub-expressions in a function body, and those applications should hold under a mapped type.The text was updated successfully, but these errors were encountered: