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

Same type evaluated differently when in a Tuple or by itself #47579

Closed
188599 opened this issue Jan 24, 2022 · 3 comments
Closed

Same type evaluated differently when in a Tuple or by itself #47579

188599 opened this issue Jan 24, 2022 · 3 comments
Labels
Not a Defect This behavior is one of several equally-correct options

Comments

@188599
Copy link

188599 commented Jan 24, 2022

Bug Report

πŸ”Ž Search Terms

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________

⏯ Playground Link

Playground link with relevant code

πŸ’» Code

Considering the following code:

type TypeWithoutTuple<T> = [T, Partial<T>];
type TypeWithTuple<T> = T | [T, Partial<T>];

interface A {
    a: number;
    b: string;
}

class A { }

const funcNotUsingTupleType = <
    T extends readonly unknown[]
    >(...args: [...{ [K in keyof T]: TypeWithoutTuple<T[K]> }]) => { }

const funcUsingTupleType = <
    T extends readonly unknown[]
    >(...args: [...{ [K in keyof T]: TypeWithTuple<T[K]> }]) => { }


funcNotUsingTupleType([new A(), {}]) // infers the typying <[A]>(things_0: ThingNoTuple<A>) => void

funcUsingTupleType([new A(), {}]) // infers the typying <[{}]>(things_0: TypeWithTuple<{}>) => void

πŸ™ Actual behavior

The same calls to funcNotUsingTupleType and funcUsingTupleType have different inferred typyings, even when they are evaluating the same thing.

πŸ™‚ Expected behavior

The same calls to funcNotUsingTupleType and funcUsingTupleType to have the same inferred typyings.

@188599 188599 changed the title Same type evaluated differently when in conjunction with a Tuple or by itself Same type evaluated differently when in a Tuple or by itself Jan 24, 2022
@RyanCavanaugh RyanCavanaugh added the Not a Defect This behavior is one of several equally-correct options label Jan 24, 2022
@RyanCavanaugh
Copy link
Member

These are both valid inferences.

In the first case, because TypeWithoutTuple is just a tuple type, we can safely collect inference candidates based on the tuple positions.

In the second case, TypeWithTuple has the possibility of T, so it's not safe to collect inference candidates from the tuple positions, so instead the type of the array literal gets computed (and reduced to { }, since we can't see at this point that {} is supposed to be a Partial<A>).

This might be solved with #30134 but in general an inference onto type S<T> = T | U<T> is not going to be able to produce as good as inference as one without it.

@188599
Copy link
Author

188599 commented Jan 24, 2022

I see, I figured it might be worth bringing this up here because I had this working with multiple generic types before, something like this:

const funcUsingTupleTypeWithoutRestParamsGeneric = <T1, T2, T3>(...args: [TypeWithTuple<T1>, TypeWithTuple<T2>?, TypeWithTuple<T3>?]) => { }

funcUsingTupleTypeWithoutRestParamsGeneric([new A(), {}]) // infers the typing <A, unknown, unknown>(args_0: TypeWithTuple<A>, args_1?: unknown, args_2?: unknown) => void

And I figured that converting to this other way I mentioned on the issue would work just as well.

@github-actions
Copy link

github-actions bot commented Jun 8, 2023

This issue has been marked as 'Not a Defect' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Not a Defect This behavior is one of several equally-correct options
Projects
None yet
Development

No branches or pull requests

2 participants