Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Add assignability rules for when the target is a conditional type#27932

Closed
weswigham wants to merge 4 commits into
microsoft:mainmicrosoft/TypeScript:mainfrom
weswigham:infer-conditional-class-thisweswigham/TypeScript:infer-conditional-class-thisCopy head branch name to clipboard
Closed

Add assignability rules for when the target is a conditional type#27932
weswigham wants to merge 4 commits into
microsoft:mainmicrosoft/TypeScript:mainfrom
weswigham:infer-conditional-class-thisweswigham/TypeScript:infer-conditional-class-thisCopy head branch name to clipboard

Conversation

@weswigham

Copy link
Copy Markdown
Member

Inspired by looking into #27014
Fixes #26933
Steals from #27589

This adds assignability rules for relating types when the target is a conditional type. We only check for conditional type target assignability when:

  • The target is not distributive or,
  • The distributive conditional type's check type cannot be instantiated to never
    Given these circumstances, a type is assignable to the conditional in question if
  • it is assignable to both branches of the conditional, or
  • if the conditional type looks to be always true (yet has infer types, preventing simplification) and it is assignable to the intersection of the instantiated constraint of the true branch and the uninstantiated constraint (this allows for "independent" infer types to not interfere with true branch assignability, whilst still preserving the assignment-blocking part of the existential-like behavior of the infer types).

@weswigham weswigham force-pushed the infer-conditional-class-this branch from 7652906 to f590103 Compare October 17, 2018 02:10
@jack-williams

jack-williams commented Oct 23, 2018

Copy link
Copy Markdown
Collaborator

When you write:

it is assignable to the intersection of the instantiated constraint of the true branch and the uninstantiated constraint.

By instantiated are you referring to the instantiation of the infer parameters? Would it be possible to write a small example that shows the difference between the proposed behaviour, and the behaviour if you only consider the uninstantiated true constraint (as opposed to the intersection)?

I have a hard time translating the rules into concrete examples, so it would be greatly appreciated!

@dgreensp

dgreensp commented Jan 8, 2020

Copy link
Copy Markdown

Does this address the unsoundness in #26945?

@sandersn

Copy link
Copy Markdown
Member

This experiment is pretty old, so I'm going to close it to reduce the number of open PRs.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Author: Team Experiment A fork with an experimental idea which might not make it into master

Projects

None yet

Development

Successfully merging this pull request may close these issues.

T should be assignable to A extends B ? C : D if it is assignable to both C and D

5 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.