Function signature overload with rest parameter: TS picks the wrong signature

[denis-migdal]

🔎 Search Terms

function signature wrong pick

As asked, this is a rewrite of the issue #62000

🕗 Version & Regression Information

Tested with the nightly build.

⏯ Playground Link

Playground Link

💻 Code

type         OPTIONS = Record<string, unknown>;
type DEFAULT_OPTIONS = {css: string[]};
type    TEST_OPTIONS = {css: any[]   };

let test: DEFAULT_OPTIONS = {} as TEST_OPTIONS; // TEST_OPTIONS can be cast into DEFAULT_OPTIONS.

/**************************************************************/
{
    function LISS( args: DEFAULT_OPTIONS) : true
    function LISS( args: OPTIONS,
                   ...extensions: unknown[]): false

    function LISS(args: OPTIONS,
                 ...extensions: unknown[]): boolean {
        return {} as boolean
    }

    const a = LISS({} as TEST_OPTIONS); // is false, should be true
    const b = LISS({} as DEFAULT_OPTIONS);
}

🙁 Actual behavior

typeof aisfalsewhen it should betrue`: 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

As asked, this is a rewrite of the issue #62000

Using [unknown, ...unknown[]] 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.

[Andarist]

This is a product of:

• overload matching using a subtype relationship to check if arg types are compatible with param types
• any not being considered a subtype of just anything (?) - so when css properties are compared any doesn't match string
• but then the second overload matches this through indexSignaturesRelatedTo because the source type has an inferrable index. In there, any[] quickly matches unknown in isSimpleTypeRelatedTo

[denis-migdal]

More precision : in the playground example, you can see that, if the second signature uses [unknown, ...unknown[]], then the first signature is used.

Is was my understanding that TS picks the first signature that matches the call.
However, it seems the first signature is picked depending on how the second signature is written ( using unknown[] or [unknown, ...unknown[]] ).

[Andarist]

Internally, it happens exactly because of the reasons I have outlined above. I'm not saying this is good/bad - I'm just mentioning implementation details that lead to this so the TS team could use this information when responding to this issue.

The problem is that overload matching used a different kind of a relationship (subtype) than a single-signature codepath. And that subtype relationship, is not that well-defined publicly (from what I know). That's why, for you - the user, it looks as if the formulation of the second one changes the order matching.

But it doesn't. They are still matched from the top to the bottom. But the first overload fails (using subtype relationship!), then second one succeeds. When you change the second signature to use a variadic tuple then the first overload still fails, then the second one fails (any[] doesn't satisfy [unknown, ...unknown[]]) but then the first one succeeds because the whole process is retried but this time using the regular assignable relationship (so this time string target is just fine with any source).

[Harsherr]

Root Cause

TypeScript overload resolution picks the first matching overload by argument types (not by assignability direction).

TEST_OPTIONS can be assigned to DEFAULT_OPTIONS, but not the other way around.

But TEST_OPTIONS is not structurally identical to DEFAULT_OPTIONS (css: any[] vs css: string[]), so

LISS(args: DEFAULT_OPTIONS): true does not match (because TEST_OPTIONS is not a subtype of DEFAULT_OPTIONS)

So it falls back to the second overload (the broad OPTIONS one)

[RyanCavanaugh]

@Andarist 's analysis is correct. Using the subtype relationship for the first overload pass is critical for making overload resolution work "correctly".

[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.