Subclass doesn't produce same errors as base class with invariant type parameter annotation

[jedwards1211]

Bug Report

With class Foo<in out T = any>, TS correctly decides that Foo<string> doesn't extend Foo<string | number>. And yet, it incorrectly decides that class StringFoo extends Foo<string> extends Foo<string | number>.

🔎 Search Terms

invariant in out type parameter annotation subclass

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "invariant", "bivariant", "in out", and "variance"

⏯ Playground Link

Playground Link

💻 Code

export abstract class Foo<in out T = any> {
  abstract _parse(input: unknown): T;
}

export class StringFoo extends Foo<string> {
  _parse(input: unknown): string {
    return String(input);
  }
}

// @ts-expect-error
const a: Foo<string | number> = null as any as Foo<string>

// @ts-expect-error ❌
const b: Foo<string | number> = null as any as StringFoo

🙁 Actual behavior

TypeScript thinks StringFoo extends Foo<string | number>.

🙂 Expected behavior

If Foo<string> doesn't extend type X, then class StringFoo extends Foo<string> shouldn't either.

[RyanCavanaugh]

Variance annotations only change the behavior when a variance-based type comparison is occurring. StringFoo isn't an instantiation of Foo, so no variance-based comparison is occurring (it's structural).

In general, you should not ever write a variance annotation that does not match the structural behavior of a type.

[jedwards1211]

I had read in Anders' original PR that invariant annotations are assumed to hold, but considering how icky the inconsistency feels here, I think it would be better if TS reported an error that the structural behavior of the type isn't invariant.

[RyanCavanaugh]

The main scenario of variance annotations is to let you write the correct variance when our own measurement algorithm goes awry. If we errored when the measured variance didn't match the annotated variance, then you wouldn't be able to do that.

[jedwards1211]

Okay, I understand...still, this is very confusing and troubling behavior to encounter when trying advanced features like this out for the first time; it's an uncomfortable "can I trust what's happening inside the black box" kind of feeling. Do you think there's anything that can be done about it? I think for anyone who's used to thinking about things in mathematical ways this behavior will seem frustratingly anti-mathematical.

[RyanCavanaugh]

The mathematical foundation here is actually quite clear. You have to remember that variance is a concept that relates an input to an output. We can talk about the variance of generic type, because it's a function that produces an output from an input. The variance is only over the type parameters; the type itself cannot be said to have any variance per se, because there's not a
relevant input to consider.

Like, if we say f(x) is covariant on x -- f(a) > f(b) iff a > b -- then we can meaningfully do a variance-based comparison that f(10) > f(4) because 10 > 4. But we can't use variance to discuss the question of f(10) > 8; we have to evaluate f(10) and see how that compares to 8 (a structural comparison, if you will).

Properly interpreted in that regard, StringFoo plainly cannot be subject to a variance comparison, because it has no inputs.

[jedwards1211]

I'm sorry for my frustrated language, I've been having a rough week trying to figure out how to solve potentially infinite type errors.
To try to be constructive, I think the following would be a helpful statement we could add to the docs (if there's a docs page for variance annotations yet? So far I've only been able to find the blog post and PR). Correct me if I'm still misunderstanding:

If a parameter of type T has an invariant (in out) annotation, TS will use that annotation only when comparing two instances of exactly T; but when comparing to any subtype of T, whether a subclass or T & <another type> etc, it will ignore the declared invariance and fall back to structural comparison.

I'm still not sure I exactly follow what you mean in terms of functions...I was thinking Foo<string | number> is basically f(string ∪ number) and class StringFoo is equivalent to Foo<string> i.e. f(string). Or at least equivalent to f(string) ∩ x for some x I don't know the value of. But I don't know if f(string) ∩ x ⊆ f(string ∪ number) depends on that x or if it can be determined to be false solely on the basis of the (declared) invariance of f's parameter.

[microsoft-github-policy-service]

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

[microsoft-github-policy-service]

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

[microsoft-github-policy-service]

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

[microsoft-github-policy-service]

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

[RyanCavanaugh]

@jedwards1211 FYI I'm working on an unrelated blog post explaining variance so I'm sort of using this issue to kick around various explanatory concepts to see how they land. Grain of salt, etc..

I think the crux of this is that writing

// some_mod being 'in' ,'out', 'in out', etc...
type Foo<some_mod T> = { x: T }

type FooString = Foo<string>;

produces a type that is, for all intents and purposes, this:

type FooString = { x: string };

and not this:

type FooString = { some_mod x: string };

because

{ some_mod x: string };

is not a concept in TypeScript (nor is it really clear how one would make such a concept even work).