Unstable type inference when generic is inferred from a return type #29771

Activity

1. dragomirtitian commented on Feb 6, 2019

   

   Titian Cernicova-Dragomir (dragomirtitian)

   on Feb 6, 2019

   Contributor

   More actions

   A samller example of what you are trying to do would be:

   declare function useDerivedState<T>(
     initializer: (previous: T ) => T
   ): T
   
   const state = useDerivedState(previous => 0) // state is {}

   Just as an opinion, I don't think typescript can deal with this scenario well at the moment. It's probably trying to figure out the type of the callback, and to do that it needs a type for the parameter, and there is nowhere to get that from so goes with the default of {}.

   👍React with 👍1Reacted by Ryan Cavanaugh
2. Jessidhia commented on Feb 6, 2019

   

   Jessica Franco (Jessidhia)

   on Feb 6, 2019

   Last edited by Jessidhia

   Author

   More actions

   Yeah, that is probably the central cause, but the odd thing is that the inference was so unstable and would change by just interacting with the IDE even without changing the source code.

   ---

   Luckily, because I only actually needed a small portion of the previous that has a very simple type to be able to calculate the next value, I managed to refactor things such that I can use ReturnType to get the fairly complex derived type of previous itself.

   useDerivedState(
     (previous: ReturnType<typeof deriveFoo>) =>
       deriveFoo(previous !== undefined ? previous.foo.bar : undefined)
   )
   
   function deriveFoo(argument?: BarType) {
     return fooFactory(argument, factoryOptions)
   }

   😕React with 😕1Reacted by Titian Cernicova-Dragomir
3. Ryan Cavanaugh (RyanCavanaugh)

   added

   Design LimitationConstraints of the existing architecture prevent this from being fixedConstraints of the existing architecture prevent this from being fixed

   on Feb 14, 2019
4. RyanCavanaugh commented on Feb 14, 2019

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Feb 14, 2019

   Member

   More actions

   Our inference system can't really deal with a t => t' kind of function to do inferences from both sides to figure out what's going on. Sometimes language service operations manage to avoid noticing, but this is really a side effect.
5. flaviaan commented on Mar 11, 2019

   

   Flavian Desverne (flaviaan)

   on Mar 11, 2019

   Last edited by flaviaan

   More actions

   Same here, which is very sad 😞

   interface ServerConfig<T, U, V> {
     server: () => T
     startServer: (param: T) => U
     stopServer: (param: U) => V
   }
   
   function config<T, U, V>(cfg: ServerConfig<T, U, V>): ServerConfig<T, U, V> {
     return cfg
   }

   

   Expected behavior:

   ServerConfig to be of type

   ServerConfig<{ foo:'bar' }, string, number>

   Actual behavior:

   ServerConfig<{ foo:'bar' }, {}, number>

   Playgroung link

   The return types are sometimes inferred, sometimes not, which makes it unreliable 😢
6. MicahZoltu commented on Feb 9, 2020

   

   Micah Zoltu (MicahZoltu)

   on Feb 9, 2020

   More actions

   Oddly, when you give the compiler less information it gets the inference correct. I don't know why this is, and perhaps is related to the "unreliability" that others were talking about:

   interface Apple<T> {
     parse: (value: string) => T,
     stringify: (value: T) => string,
   };
   declare function eatApple<T>(apple: Apple<T>): void
   eatApple({
       // infers `T` as `unknown`
       parse: value => Number.parseInt(value),
       // errors because `value` is `unknown`
       stringify: value => value.toString(),
   })
   eatApple({
       // infers `T` as `number`
       parse: (value: string) => Number.parseInt(value),
       // works because `value` is `number`
       stringify: value => value.toString(),
   })
   
   interface Banana<T> {
       parse: (value: string) => T
   }
   declare function eatBanana<T>(banana: Banana<T>): void
   eatBanana({
       // `T` correctly inferred as `number`
       parse: value => Number.parseInt(value),
   })

   Of note is that an instance of Apple incorrectly inferred T as unknown when given an untyped parse function, however Banana correctly inferred T as number when given the exact same function. The only difference between the two is that Apple has additional properties.
7. threehams commented on Feb 9, 2020

   

   David Edmondson (threehams)

   on Feb 9, 2020

   More actions

   That makes sense, though. Inference only breaks down when the generic is used in both a return type position and another position.
8. Ryan Cavanaugh (RyanCavanaugh)

   closed this as completedon Jun 1, 2021