Parameters typed as unknown even when the function type has the correct types #57654

Activity

1. Andarist commented on Mar 5, 2024

   

   Mateusz Burzyński (Andarist)

   on Mar 5, 2024

   Contributor

   More actions

   This is the behavior that starts in version 4.9, and I reviewed the FAQ for entries about function types
   All the versions prior to 4.9 have both scenarios with the params typed to unknown

   I'm pretty sure that the observed behavior change is related to #50994
2. RyanCavanaugh commented on Mar 6, 2024

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Mar 6, 2024

   Member

   More actions

   (Speaking only to the reduced repro; the longer one is way too long)

   These functions as written are sort of bad beyond salvaging through inference. There aren't any "good" inference sites for T so end up having observable differences between falling back to the default vs the constraint.

   I guess I'd argue that unknown is the correct behavior here, since a body of these functions could call it with non-"wtf" values:

   function noDefaultTypeParameter<T extends Callback>(f: Listener<T>) {
     f(423);
   }

   But there's really no reason to write Listener this way; it's already distributive and null and undefined will not match the infer. Writing it this way:

   type Listener<T> =
     T extends (arg: infer U) => unknown
       ? (arg: U) => unknown
       : never

   causes both function's behavior to align, and correctly makes it an error to invoke f(423) in the bodies.

   Barring a more realistic repro I don't have a well-justified behavior change.
3. Ryan Cavanaugh (RyanCavanaugh)

   added

   Needs More InfoThe issue still hasn't been fully clarifiedThe issue still hasn't been fully clarified

   on Mar 6, 2024
4. Didas-git commented on Mar 6, 2024

   

   DidaS (Didas-git)

   on Mar 6, 2024

   Author

   More actions

   I have reduced the big example as much as i could to reflect what im really using it for, i also added some more examples (one of the examples just left me speachless because i really dont understand whats going on)
   Here is the link
5. RyanCavanaugh commented on Mar 6, 2024

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Mar 6, 2024

   Member

   More actions

   Can I get more concrete/descriptive "what I expected to happen"s than "Uhm??". I know it's obvious to you but it's a lot of work for me to reconstruct your mental state
6. Didas-git commented on Mar 6, 2024

   

   DidaS (Didas-git)

   on Mar 6, 2024

   Author

   More actions

   Well, typescript reports the type of the function ready so i expected the arguments to be typed as well, but what really left me speachless and with no more ideas was the last one where the function is typed to (arg: string) => unknown yet the argument is typed as something completely different, not even unknown
7. Forlini91 commented on Mar 7, 2024

   

   Marco (Forlini91)

   on Mar 7, 2024

   Last edited by Forlini91

   More actions

   It seems a problem with optional properties of objects.
   You're iterating all keys in Transformers [K in keyof T], and Transformers has the optional property "ready".
   When you do T[K], it find that optional property and read it as <type of that property> | undefined, and this makes the conditional type T[K] extends { handler: ... fail, because it doesn't match the "undefined" part of the type.

   Adding & {} (as you did) entirely remove the "undefined" from the type, and this explains why it works.
   Changing the conditional type to T[K] extends undefined | { handler: ... also works, because we're including the possibility for undefined.