Function signature overload with rest parameter : TS picks the wrong signature when called with argument `any[]`

[denis-migdal]

🔎 Search Terms

function signature wrong pick

🕗 Version & Regression Information

• Tested with the nightly build.

⏯ Playground Link

Playground Link

💻 Code

type Extension = {
    args: Record<string, any>
};

// black magic from https://www.geeksforgeeks.org/union-type-to-intersection-type-in-typescript/
type UnionToIntersection<U> = (
    U extends any ? (k: U) => void : never
) extends (k: infer I) => void
    ? I
    : never;

type Args<T extends Extension[]> = UnionToIntersection<T[keyof T & number]["args"]>

export function LISS(args: NoInfer<Args<[{args: {css: string[]}}]>>)
                                        : true
export function LISS<T extends Extension[]>( args: NoInfer<Args<T>>,
                                        ...extensions: T): false
export function LISS<T extends Extension[]>(args: NoInfer<Args<T>>,
                                    ...extensions: T): boolean {
                                        return {} as boolean
                                    }

const a = LISS({ css: [] as any[]}); // should be true
const b = LISS({ css: [] as string[]}); // ok

🙁 Actual behavior

typeof a is false when it should be true : i.e. the second signature overload is chosen.

🙂 Expected behavior

typeof a should be true : i.e. the first signature overload should be chosen.

Additional information about the issue

Using T extends [Extension, ...Extension[]] fixes the issue in the example (force the second signature to have at least one extension). But the underlying issue might manifest in other cases.

Note: It would be simpler to write :

const exts = [{args: {css: string[]}}];

export function LISS<T extends Extension[] = typeof exts>(
                                        args: NoInfer<Args<T>>,
                                        ...extensions: T = exts): ...`

But TS doesn't allow us to do so, hence the function signature overload.

[jcalz]

Whatever your issue is, NoInfer<Args<[{args: {css: string[]}}]>> is a weird thing to write and doesn't seem like it changes anything if I replace it with just {css: string[]}. Maybe you should do this so as not to distract from whatever you're doing in the second call signature?

[MartinJohns]

Also relevant: #43077 (comment)

We don't really support uses of UnionToIntersection; this operation is ill-defined.

[denis-migdal]

Whatever your issue is, NoInfer<Args<[{args: {css: string[]}}]>> is a weird thing to write and doesn't seem like it changes anything if I replace it with just {css: string[]}. Maybe you should do this so as not to distract from whatever you're doing in the second call signature?

The original code is a little more complex.

But indeed, for the issue, I should have simplified it further.

[RyanCavanaugh]

This repro is too weird to try to make sense of. If you have something that doesn't have UnionToIntersection or intentionally-uninferable type argument positions, please log a new issue, but this doesn't seem to represent an identifiable problem.

[denis-migdal]

Ok, I'll try to simplify the minimal example and post a new issue.

The original code, is a function that takes a list of Mixins, and an object which regroups options that will be given the the mixins :

function Foo(base, opts) {
     return X extends base {
     }
}

function Faa(base, opts) {
     return X extends base {
     }
}

class X extends Liss(opts, Foo, Faa) {

}

[typescript-bot]

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