Destructuring array result of function with generics call sometimes lead to type loss #32003

Activity

1. ahejlsberg commented on Jun 21, 2019

   

   Anders Hejlsberg (ahejlsberg)

   on Jun 21, 2019

   Member

   More actions

   This one is a bit strange. In examples 1 and 2, the call to foo() is contextually typed by the implied types of the array destrucuring patterns ([any, any] and [any, any, any] respectively). Since foo is generic and we have a contextual type, we perform generic return type inference (#16072). In example 2 where the arities of the tuple types match we then infer any for T, and since there is nothing else to make inferences from, that's what we end up with. In the other examples, we make no inferences for T at all and therefore end up with the default {}.

   Ideally we shouldn't make any inferences from the implied types of the destructuring patterns, but in other scenarios we do want a contextual type of a tuple type to indicate that array literals should be treated as tuples. So we have conflicting goals and there isn't an obvious simple fix. Add to that the anti-pattern of having a type parameter that isn't used in anywhere in the parameter list (it's basically just a disguised type assertion) and I think we'll call this a design limitation.
2. Anders Hejlsberg (ahejlsberg)

   added

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

   on Jun 21, 2019
3. miloszpp commented on Aug 22, 2019

   

   Milosz Piechocki (miloszpp)

   on Aug 22, 2019

   Contributor

   More actions

   Just wanted to point out that this issue impacts typing hooks in React.

   const [pill, setPill] = useState();

   The type of pill is inferred to any while it should be undefined according to the type definition:

   function useState<S = undefined>(): [S | undefined, Dispatch<SetStateAction<S | undefined>>];
4. danieloprado commented on Sep 10, 2019

   

   Daniel Prado (danieloprado)

   on Sep 10, 2019

   More actions

   A little workaround:

   function foo<T = {}>(): [T, string, number, undefined] { // <~ add a 4th return
   	let a: T;
   	return [a, 'foo', 2, undefined]; // <~ return the 4th value as undefined
   }
   
   // 1
   const [a, b] = foo();
   // a: {}, b: string
   
   // 2
   const [x, y, z] = foo();
   // x:{}, y: string, z: number 👍
   
   // 3
   const res = foo();
   const [x2, y2, z2] = res;
   // x2: {}, y: string, z: number
   
   // 4
   const [x3, y3, z3] = foo<{ bar: string }>();
   // x3: { bar: string }, y3: string, z: number

   👍React with 👍1Reacted by Nicholas Firth-McCoy
5. TLadd commented on Feb 6, 2020

   

   Thomas Ladd (TLadd)

   on Feb 6, 2020

   Last edited by TLadd

   More actions

   Ran into this as well:

   export interface Sizes {
     width: number | null;
     height: number | null;
   }
   
     declare function useResizeAware<S = Sizes>(
       customReporter?: (target: HTMLElement | null) => S
     ): [string, S];
   
   
   const [a, b] = useResizeAware();
   
   const c = useResizeAware();
   const d = c[1]
   

   So in my case the generic does appear in the arguments but it is an optional parameter. d is properly typed as Sizes while b is of type any.

   Using overrides is another solution that fixed this for me:

     declare function useResizeAware(): [string, Sizes];
     declare function useResizeAware<S>(
       customReporter: (target: HTMLElement | null) => S
     ): [string, S];
   
6. luokuning commented on Mar 25, 2020

   

   LK (luokuning)

   on Mar 25, 2020

   More actions

   Looks like TypeScript v3.8 have fixed that issue?

   👍React with 👍1Reacted by Mathieu Savy
7. mrblackus commented on Jun 24, 2020

   

   Mathieu Savy (mrblackus)

   on Jun 24, 2020

   Author

   More actions

   In can confirm that issue is fixed in both TS 3.8 and 3.9. Thanks!

   🚀React with 🚀3Reacted by Piotr Kowalski, Gaurav and Quan Tran
8. Mathieu Savy (mrblackus)

   closed this as completedon Jun 24, 2020