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
constfInferred=({ a =0}={})=>a;// const fInferred: ({ a }?: { a?: number; }) => numberconstfAnnotated: typeoffInferred=({ a =0}={})=>a;// error!// ----------------------------------> ~// 'a' does not exist on type '{ a?: number | undefined; } | undefined'constfAnnotationIntensifies: typeoffInferred=({ a =0}: {a?: number}={})=>a;// no error now
Expected behavior:
No error assigning to fAnnotated. The arrow function's parameter should be compatible with the contextual type, since this contextual type comes from the parameter type of fInferred with identical JS code.
Actual behavior:
The destructured parameter a of fAnnotated generates a warning. It is no longer inferred as an optional parameter. You can work around this by explicitly annotating the parameter as in fAnnotationIntensifies but it's not clear why this should be necessary.
This issue came up in this Stack Overflow question where the person wants to explicitly annotate things with their inferred types. It would be nice to know if the behavior here is somehow intentional or correct, or if it's a bug or limitation.
TypeScript Version: 3.9.0-dev.20200306
Search Terms: annotation, default, optional, destructuring
Code
Expected behavior:
No error assigning to
fAnnotated
. The arrow function's parameter should be compatible with the contextual type, since this contextual type comes from the parameter type offInferred
with identical JS code.Actual behavior:
The destructured parameter
a
offAnnotated
generates a warning. It is no longer inferred as an optional parameter. You can work around this by explicitly annotating the parameter as infAnnotationIntensifies
but it's not clear why this should be necessary.This issue came up in this Stack Overflow question where the person wants to explicitly annotate things with their inferred types. It would be nice to know if the behavior here is somehow intentional or correct, or if it's a bug or limitation.
Playground Link: Provided
Related Issues:
#35160 is quite similar but is missing the part where the compiler infers the unannotated function to be of the type annotated.
The text was updated successfully, but these errors were encountered: