You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was thinking of a simpler setting and found that handling of normal rest parameters isn't perfect. These two are not the same issue given that this one doesn't result in a compile error.
The text was updated successfully, but these errors were encountered:
Technically that arrow function shouldn’t be assignable to Func at all since Func can legally be passed zero arguments but arg is required. Seems like an oversight in function assignability checking.
Personally I think TypeScript could allow receiving parameters that may not exist from rest parameters, similarly to how TypeScript currently allows accessing array elements that may not exist. Considering noUncheckedIndexedAccess in that case may be nicer.
Either way, current behavior is unsafe, so a fix is desired.
Just stumbled upon this and I second the @uhyo here. I think that an added | undefined would be slightly better than an assignability error. It would make it easier to handle more crazy scenarios with the "source" rest parameter being a union of tuple types (potentially with different lengths etc).
It wouldn't introduce any unsoundness. After all, the declared function could still be called soundly - it would just affect the types visible in the implementation of this function and that would increase the type safety
Bug Report
🔎 Search Terms
function parameter contextual contextually rest undefined
🕗 Version & Regression Information
3.3.3333, 4.5.0-dev.20210925
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
(Under
strict: true
, and alsonoUncheckedIndexedAccess: true
as a bonus)The type of
arg
is inferred asnumber
althoughundefined
could flow in.🙂 Expected behavior
The type of
arg
should benumber | undefined
.⛰️ Context
Related: #45972
I was thinking of a simpler setting and found that handling of normal rest parameters isn't perfect. These two are not the same issue given that this one doesn't result in a compile error.
The text was updated successfully, but these errors were encountered: