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

Nested conditional type with generic tuple argument always expands to false branch. #30708

Open
Veetaha opened this issue Apr 2, 2019 · 5 comments
Labels
Bug A bug in TypeScript
Milestone

Comments

@Veetaha
Copy link

Veetaha commented Apr 2, 2019

TypeScript Version: next (3.4.0-dev.20190330), latest (3.4.1)

Search Terms:

  • tuple conditional type
  • tuple compare
  • tuple comparison

Code

type Not<T extends boolean> = [T] extends [true] ? false : true;
type NoOp<T extends boolean> = Not<Not<T>>; // always expands true (see intellisense)

type t0 = Not<Not<false>>; // false
type t1 = NoOp<false>;     // true (but should be false)

Expected behavior:
Type t1 must be false and NoOp must be of the nested conditional type that depends on T, but not of simple true unit type.
Actual behavior:
As you see, something is broken when you use generic argument for tuple comparison in conditional type, because when you expand your types manually (t0 is an expanded representation of t1) it works as expected.

Playground Link:

Klick me

Related Issues:

This bug report originated from my stackoverflow question.

Additional credits to @dragomirtitian and @fictitious for helping and localizing the bug to a minimal representation.

@jack-williams
Copy link
Collaborator

jack-williams commented Apr 2, 2019

Even smaller repro (perhaps not 'smaller'):

type Inner<T> = [T] extends [true] ? false : true;
type Outer<T> = [Inner<T>] extends [true] ? 1 : 2; // Already resolved to 2.

Most likely the wildcard instantiation for Outer is causing Inner to resolve to false, therefore the condition in Outer is always false under the most permissive instantiation and will resolve to 2.

@jack-williams
Copy link
Collaborator

This is technically a duplicate of #30020

@vipcxj
Copy link

vipcxj commented Apr 30, 2019

This is technically a duplicate of #30020

This issue is closed. just because someone provide a workaround. No one care the bug itself. it may cause some other problem which has not workaround.

@sktw
Copy link

sktw commented Feb 1, 2020

I found a similar issue while writing a conditional type IsOptional to test whether a single property is optional:

// From this answer https://stackoverflow.com/a/52991061/374328

type OptionalKeys<T> = { [K in keyof T]-?: {} extends Pick<T, K> ? K : never }[keyof T];

// Test if a single property on type T is optional

type IsOptional<T, K extends keyof T> = {} extends Pick<T, K> ? true : false;

// example interfaces

interface I {
    x: string;
    y?: number
}

type IX = IsOptional<I, 'x'> // false - ok
type IY = IsOptional<I, 'y'> // true - ok

interface J extends I {
    y: number;
}

type JX = IsOptional<J, 'x'> // false - ok
type JY = IsOptional<J, 'y'> // false - ok

// issue

type TX<T extends I> = IsOptional<T, 'x'>; // expands to false - correct since x required in I
type TY<T extends I> = IsOptional<T, 'y'> // expands to false - incorrect - y might be optional in T

Playground

IsOptional itself seems to work correctly. Type TX expands to false, which while correct may be by accident. However, type TY also expands to false, which is incorrect.

Finally, note that the following implementation of IsOptional doesn't result in the same problems:

type IsOptional<T, K extends keyof T> = K extends OptionalKeys<T> ? true : false;

@jcalz
Copy link
Contributor

jcalz commented Mar 5, 2024

Looks like the OP issue got resolved somewhere along the way, but similar issues keep cropping up (see SO question). Is there some more general bug report for this? Should we close this one and open a new one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript
Projects
None yet
Development

No branches or pull requests

6 participants