Contravariance with optional arguments causes runtime errors

[thomasttvo]

🔎 Search Terms

contravariance, function types, crash, optional arguments

🕗 Version & Regression Information

Not sure, but it may cause runtime crash

⏯ Playground Link

No response

💻 Code

const x = (first: number, second?: number) => {
   // some logic here
}; 
const y: (first: number) => void = x; // ok
const z: (first: number, second: string) => void = y; // ok

z(123, '123'); // TS says ok, but you'll get a runtime issue.

🙁 Actual behavior

A function with optional parameters can get assigned to a function variable with less parameters. At first glance this is ok because you'd think x can be called without second, but it will cause issues when that variable gets assigned to a function variable with more parameters.

🙂 Expected behavior

x should not be assigned to y

Additional information about the issue

No response

[DanielRosenwasser]

It's not exactly about variance, but yes, optionality and aliasing mix pretty poorly in some contexts, and it comes up with objects too. There isn't much we're planning to do here, it is an intentional trade-off in usability and soundness.

The closest thing I can find in the FAQ is https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters

[fatcerberus]

The same tradeoff applies to objects, fwiw - it’s not specific to functions.

• { foo: string, bar: string } is assignable to { foo: string }
• … is in turn assignable to { foo: string, bar?: number }
• …and now .bar is a string even though the types say it’s a number

[thomasttvo]

I see, thank you both. I see the support is intentional, but this could cause a variable with an unexpected type gets passed around the code base, which lowers confidence in the advertised type of any variable. Is it possible to at least disallow this kind of behavior in strict mode, or perhaps a lint rule so users can optionally turn it on?

[DanielRosenwasser]

I think the closest thing would be exact types #12936 because it could(?) disallow the case of {| foo: string |} being assignable to {| foo: string, bar?: number |}.

But that doesn't cover the original issue around function parameter lists.

[typescript-bot]

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