Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default parameter not accepted for conditional type although assignable to both branches #39521

Closed
jeysal opened this issue Jul 9, 2020 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@jeysal
Copy link

jeysal commented Jul 9, 2020

TypeScript Version: Nightly playground 2020-07-09

Search Terms: conditional type not assignable, conditional branch assignable, default parameter assignable
(there are so many issues related to conditional types it's hard to tell which title may be related)

Code

Close to my use case:

type Options<T> = {
    t: T,
    flag?: T extends string ? boolean : false,
}

function f<Y>({ t, flag = false }: Options<Y>) { }

As minimal as I can get it, probably still the same cause:

type Param<T> = T extends string ? boolean : boolean;
function fn<T>(param: Param<T> = false) { }

Expected behavior:

No type error (other than unused parameters).

Note: This could be two separate bugs.
Example 1: The default parameter should be inferred to false, not boolean, like it is in const x = false, so if anything the error message should be Type 'false' is not assignable to [...]. It also does not seem to help to default to [...] = (false as false) or [...] = (false as const)
Example 2: Even with [...] ? boolean : boolean TS incorrectly does not allow to default to a boolean or false.

Actual behavior:

Example 1:

Type 'boolean' is not assignable to type 'Y extends string ? boolean : false'.(2322)

Example 2:

Type 'boolean' is not assignable to type 'Param<T>'.(2322)

Playground Link:
Example 1:
Playground Link
Example 2:
Playground Link

Related Issues:

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Jul 9, 2020
@RyanCavanaugh
Copy link
Member

Fix is in progress at #30639. It's a bit of a sticky wicket.

@jeysal
Copy link
Author

jeysal commented Jul 9, 2020

Cool, looks like #26933 which that PR aims to fix (among other issues) is sufficiently similar to assume that this issue will be fixed by that as well. Closing as duplicate 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants