[6.x] Getting'unassingable to type' when returning value from method that needs to infer generic from parameters

[spaceemotion]

🔎 Search Terms

is unassingable to type return value generic, unassingable to type return value

🕗 Version & Regression Information

• This changed between versions 5.9.3 and 6.0.3

⏯ Playground Link

https://www.typescriptlang.org/play/?noUncheckedIndexedAccess=true&useDefineForClassFields=true&noUnusedLocals=true&noUnusedParameters=true&target=99&isolatedModules=true&verbatimModuleSyntax=true&isolatedDeclarations=false&strictBuiltinIteratorReturn=true&allowImportingTsExtensions=true&noUncheckedSideEffectImports=true&ts=6.0.3#code/C4TwDgpgBAMghgIwgGygXigbysCAPYALigGdgAnASwDsBzAGigGMB7ZF84squqAXwBQA0JCgBhOGUTIIAFXDQ0AqFAA+pCjVrK1sRCh0BuISOgAlAK7VglALYQAClVuUbAN0U713LV6hmIVnIAEwAeJxZIclAAaQgQRisAa2oWAHdqAD4jEwV-Kxt7GEoyUNl0fOs7R2dXSg9MitkAbQBdXNEAOTh7ADEOeUgyqHxcamCScUlgaTkFRqUVctGIccmfOh0VAH4oAHIN2j2tqGJlglWJvSRkE5395H1kY5VX06hqCA9yIWDAx-I0FY1DIUFscDAshYxDKvXILFsIwuaymUgQMkGEEYsihSLGVwkaIx8wAFDpkCUiFBZHCEW16DpgNCoN0+gMFGUoZkGQBKdCNSxVIqUzksTLGAQAMysTBsLGoUEB4LAJJ5xEFhQgxVBmB0wNBuAIJC4mjobQqbWMKh0AHobVAAOocJLG2325VQ0KHRjwG6ZEmG4AkRh7R43PY8iUqO1QAAiLAgk1SwCgaWdhB0gOAFnICo9LADo2DDyeEeMgiAA

💻 Code

type Label = { text: string, color: string }

type CastableType =
  | string
  | Label
  ;

type RuntimePrimitive =
  | string
  | Record<PropertyKey, unknown>
  ;

type RuntimeList<T = RuntimePrimitive> = T[]

type NameForType<T extends CastableType> =
  T extends string
    ? 'string'
    : T extends Label
      ? 'label'
      : never

declare const mapTo: <TFrom extends CastableType, TTo extends CastableType>(
  list: TFrom[],
  to: NameForType<TTo>,
) => RuntimeList<TTo>;

function remap(): RuntimeList {
  const texts: string[] = [];
  
  // Works:
  // mapTo<string, Label>(texts, 'label');

  // Does not work:
  return mapTo(texts, 'label');
}

🙁 Actual behavior

The 'label' string is marked as unassignable, and i need to add generics to the mapTo call to help it infer the correct types.

Here's an image from production code (TS 6):

🙂 Expected behavior

No error, everything can be inferred just fine.

Here's an image from production code (TS 5):

Additional information about the issue

To me, this seems to be an interplay between the return value trying to pre-filter the accepted arguments? However, there should be no issue as the RuntimePrimitive kind of works as a generic fallback.

The error also goes away as soon as the return is removed, or the return value is first assigned to a variable, before returning it.

[mkantor]

Inference from the return type is relevant here (which I believe is what you meant by "an interplay between the return value trying to pre-filter the accepted arguments"). Also relevant is the fact that string is assignable to Record<PropertyKey, unknown> e.g. if you change RuntimePrimitive to string | Label things start working).

You could use NoInfer to disable inference from the return type, though at first glance the behavior you encountered does seem odd. I don't have the full picture in my head, but it feels like inference from the argument list should take priority over (or at least be on the same footing as) inference from the return value's context.

[spaceemotion]

@mkantor yeah, it does feel odd that the return type takes precedence here, especially since the assignment to a temporary variable also eliminates the error. I also would not know where to put the NoInfer - would that be on the return type? or the mapTo function?

I also checked the tsgo playground, and for some reason, the error shows up in the output, but is not being highlighted in the editor for some reason - so not sure if the behavior between 5, 6, and 7 is different altogether here.

[mkantor]

@spaceemotion The NoInfer suggestion in my comment links to a playground showing where to put it (the return type of mapTo becomes RuntimeList<NoInfer<TTo>>).

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Possible Relevant FAQs

Structural vs Instantiation-Based Inference

mapTo has to pick a TTo such that NameForType<TTo> is compatible with the literal type 'label'. In your definition, the only choice that satisfies that relation is TTo = Label.

Up through 5.9 the compiler sometimes worked that out because it was willing to perform a structural search inside the conditional type when inferring type arguments. Starting with 6.0 it switches to an instantiation-based pass that is faster but does not try to "solve backwards" through a conditional. As a result TTo is left unknown, so the parameter type is NameForType<unknown> which reduces to never, and 'label' is rejected.

Two patterns restore the missing information:

// 1. Pass the type argument explicitly
return mapTo<string, Label>(texts, 'label');

// 2. Add a contextual type that mentions TTo before the call
const result: RuntimeList<Label> = mapTo(texts, 'label');
return result;

Both make TTo = Label evident without relying on the inference path that changed in 6.0. The program will then compile on every current version.

Similar Issues

Here are the most similar issues I found

• (66%) microsoft/typescript#50180: type error when spreading mapped items inside an array

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

TypeScript shouldn’t require a manual type argument here. mapTo(texts, 'label') is valid on its own—the compiler can infer TFrom = string from the first argument and TTo = Label from the literal 'label'. The call only fails when it is immediately returned against the contextual return type RuntimeList, which indicates an inference regression introduced in 6.0. The error message ('label' is not assignable to parameter of type 'NameForType<never>') shows that inference for TTo collapses to never; that shouldn’t happen.

So this is a compiler issue, not correct-by-design behavior.

[spaceemotion]

@RyanCavanaugh Seems like the bot got a bit confused there at the end (saying it might be intentional, then saying it's a compiler issue). However, I think I have some extra info:

Even in 5.9.x, or with the NoInfer or "assign to variable"-trick, the type that gets inferred is not actually Label itself. If you look at the type that TS checked the return value against here, it was simply using the CastableType instead.

This may seem a bit weird at first, but I guess the compiler can't go the the T extends Y chain in reverse order - so that's fine. Since CastableType matches the RuntimePrimitive shape, the compiler is/was happy.

[RyanCavanaugh]

I'd really recommend using a lookup type instead of a conditional type for this case -- they're much better for the kind of "reverse" inference that's happening here.

type Label = { text: string, color: string }

type CastableType =
  | string
  | Label
  ;

type RuntimePrimitive =
  | string
  | Record<PropertyKey, unknown>
  ;

type RuntimeList<T = RuntimePrimitive> = T[]

interface NameForType {
  'string': string;
  'label': Label;
}

declare const mapTo: <TFrom extends CastableType, TTo extends keyof NameForType>(list: TFrom[], to: NameForType[TTo]) => RuntimeList<TTo>;

function remap(): RuntimeList {
  const texts: string[] = [];
  // OK
  return mapTo(texts, 'label');
}

[RyanCavanaugh]

Bisects to #58910. I don't think this is unexpected given the setup

[typescript-bot]

This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[spaceemotion]

@RyanCavanaugh saw this got auto-closed. Just to clarify - even though this seems to be a change in behavior between 5.x and 6.x it is not a bug but rather a limitation of the more stricter system (in prep. for the tsgo migration)?