Default argument doesn't constrain generic in higher-order function edge case

[texastoland]

Bug Report

🔎 Search Terms

default argument infer generic

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the entire FAQ

⏯ Playground Link

Workbench Repro

💻 Code

const inferArg = <T extends [unknown?]>(f: (...args: T) => void): typeof f => f

// also no error in strict?
inferArg((start = 0) => {}) // <[start?: unknown]>
// ^?
inferArg((start: number = 0) => {}) // <[start?: number | undefined]>

🙁 Actual behavior

Infers start as unknown.

🙂 Expected behavior

Infers start as number?. I expect the 2 calls to be equivalent.

Inference was a minor inconvenience because I'm using JSDoc. There's a separate DX issue that there was no compiler feedback on failed inference.

Is there already a ticket requesting an additional strict flag when a generic param can't be specialized and doesn't specify a default? I couldn't find it!

[RyanCavanaugh]

Parameter defaults don't act the same as type annotations because taking the more-specific type of the initializer can often defeat inference that would have otherwise succeeded. For example:

declare function callsIt<T extends string | number>(func: (arg1: T, arg: T) => void): void;
callsIt((n = 0, m = "") => null);

IOW we treat a default in this case exactly the same as its desugaring (a conditional reassignment at the top of the function body, which has no effect on the parameter type).

Is there already a ticket requesting an additional strict flag when a generic param can't be specialized and doesn't specify a default?

This happens way more often than you think it does (example: unspecified optional parameters); a flag that produced an error on this condition wouldn't be usable in practice.

[texastoland]

Thanks for the example!