String literal generic not always inferred when part of union in nested object #19632

Activity

2. Mohamed Hegazy (mhegazy)

   added

   DuplicateAn existing issue was already createdAn existing issue was already created

   on Nov 1, 2017
3. kpdonn commented on Nov 1, 2017

   

   Kevin Donnelly (kpdonn)

   on Nov 1, 2017

   ContributorAuthor

   More actions

   I read through #19497 and I think I understand what's going on in that one but I don't think this is a duplicate. In #19497 as I understand it the issue is essentially about any time a pattern like

   declare function arr<T>(val: T): Array<T> // or any type similar to Container<T>

   occurs, T is widened from a literal to string.

   In my mind that seems mostly unrelated to what is happening in my example. What seems so odd about my example and really makes me think it is a bug is the how the inference works correctly here:

   const directUnionSingle = direct("z") // inferred to be Record<"z", string>
   const directUnionArray = direct(["z", "y"]) // inferred to be Record<"z" | "y", string>

   but that same pattern fails, but only partially fails, if they are nested inside of an object:

   const nestedUnionSingle = nestedUnion({fields: "z"}) // inferred to be Record<string, string>
   const nestedUnionArray = nestedUnion({fields: ["z", "y"]}) // inferred to be Record<"z" | "y", string>
4. kpdonn commented on Nov 1, 2017

   

   Kevin Donnelly (kpdonn)

   on Nov 1, 2017

   ContributorAuthor

   More actions

   Andy (Andrewkraft) (@Andy-MS) Also more evidence that this is not a duplicate of #19497 is that all the examples in #19497 work if the generic type is constrained to extend string:

   interface Observable<T extends string> {peek(): T}
   declare function obs<T extends string>(val: T): Observable<T>
   const t: Observable<'A'> = obs('A') // now works

   declare function arr<T extends string>(val: T): T[]
   const y: "a"[] = arr("a"); // now works

   In my example the generic includes extends string so I'd expect it to work.
6. kpdonn commented on Nov 1, 2017

   

   Kevin Donnelly (kpdonn)

   on Nov 1, 2017

   ContributorAuthor

   More actions

   "z" as "z" is a workaround for the error just like in #19497 but the error itself is definitely not because of the same design limitation that is described there. Expanding on your example from #19497:

   declare function arr<T>(val: T): T[]
   const y: "a"[] = arr("a"); // error as expected
   
   declare function arr2<T>(val: T | T[]): T[]
   const y2: "a"[] = arr2("a"); // error as expected
   
   declare function arr3<T>(val: {fields: T}): T[]
   const y3: "a"[] = arr3({fields: "a"}); // error as expected
   
   declare function arr4<T>(val: {fields: T | T[]}): T[]
   const y4: "a"[] = arr4({fields: "a"}); // error as expected
   
   declare function arr5<T>(val: {fields: T | T[]}): T[]
   const y5: "a"[] = arr5({fields: ["a"]}); // error as expected
   
   
   declare function strarr<T extends string>(val: T): T[]
   const s1: "a"[] = strarr("a"); // no error as expected
   
   declare function strarr2<T extends string>(val: T | T[]): T[]
   const s2: "a"[] = strarr2("a"); // no error as expected
   
   declare function strarr3<T extends string>(val: {fields: T}): T[]
   const s3: "a"[] = strarr3({fields: "a"}); // no error as expected
   
   declare function strarr4<T extends string>(val: {fields: T | T[]}): T[]
   const s4: "a"[] = strarr4({fields: "a"}); // *** unexpected error ***
   
   declare function strarr5<T extends string>(val: {fields: T | T[]}): T[]
   const s5: "a"[] = strarr5({fields: ["a"]}); // no error as expected

   If it is the same design limitation as #19497 then why do 4 of the 5 start working after adding extends string?
7. Kevin Donnelly (kpdonn)

   added a commit that references this issue on Nov 2, 2017

   Apply isLiteralContextualType recursively for unions and intersections.

   ...

   This issue will close once commit 2b85a29 is merged into the 'master' branch.

   2b85a29
8. kpdonn commented on Nov 2, 2017

   

   Kevin Donnelly (kpdonn)

   on Nov 2, 2017

   ContributorAuthor

   More actions

   Heads up I added a PR at #19684 that would fix this behavior if accepted.
9. Wesley Wigham (weswigham)

   added a commit that references this issue on Nov 3, 2017

   As requested, include fix for microsoft#19632

   9c1bd45
10. typescript-bot commented on Nov 17, 2017

    

    TypeScript Bot (typescript-bot)

    on Nov 17, 2017

    Contributor

    More actions

    Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
11. TypeScript Bot (typescript-bot)

    closed this as completedon Nov 17, 2017
12. microsoft

    locked and limited conversation to collaborators on Jun 14, 2018