Could be instantiated with a different subtype of constraint

[quantumsheep]

Bug Report

🔎 Search Terms

not assignable to the constraint of type
could be instantiated with a different subtype of constraint

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ

⏯ Playground Link

Playground link with relevant code

💻 Code

type A = () => void;
type B = () => void;

// error
function f1<T extends A | B>(value: T): T {
  return () => value();
}

// ok
function f2<T extends A | B>(value: T): T extends A ? A : B {
  return () => value();
}

🙁 Actual behavior

The following error is happening with f1 but not f2:

Type '() => void' is not assignable to type 'T'.
  '() => void' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'B | A'.

🙂 Expected behavior

Defining f1 should work fine.

[jcalz]

I don't see a bug here.

() => value() is assignable to both A and B and therefore assignable to T extends A ? A : B, but it is not necessarily assignable to T. T might be narrower than A | B; in particular it may have other properties:

function f() { }
f.prop = "hello";

Your f1() function claims to return the same type as it takes in, so the following code compiles with no error

f1(f).prop.toUpperCase(); // okay?!

but of course there's a runtime error, since f1(f) has no prop property. That's an indication that f1 was not implemented properly. In this case, T is instantiated with typeof f, which is a different subtype of A | B than () => void is.

On the other hand, f2() only claims to return either A or B, neither of which have a known prop property, so the equivalent call with f2(f) gives the expected compiler error:

f2(f).prop.toUpperCase(); // compiler error
//    ~~~~ <-- Property 'prop' does not exist on type 'A'

So f2 is behaving well, and f1 is in error for exactly the reason the compiler states.

Playground link to code

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[acrabb]

I think I'm running into a similar issue and could use some help.

The goal is: accept a generic type of one of two options, but have one be a default. Return that type or undefined

I don't understand why T "could be instantiated with an arbitrary type" when I'm specifying that it could only be string or string[] (and assigning string if its not defined)

export default function useXParam<T extends (string | string[]) = string>(key: string): T | undefined {
  const nextRouter = useRouter()
  return nextRouter.query[key] // error   // return type of nextRouter.query[key] is: string | string[] | undefined

  // ERROR:
  // Type 'string | string[] | undefined' is not assignable to type 'T | undefined'.
  // Type 'string' is not assignable to type 'T'.
  // 'string' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'string | string[]'.ts(2322)
}

Its working as I intend from the caller perspective. (The developer can call useXParam() will behave like useXParam<string>() unless string[] is used.)
But inside the function, the return line is giving error TS 2322