Unrelated interface causes assignability to change

[dragomirtitian]

🔎 Search Terms

5.3 regression

🕗 Version & Regression Information

• This changed between versions 5.3.0-dev.20230823 and 5.3.0-dev.20230824

⏯ Playground Link

Playground Link

💻 Code

export { }
interface Map<V> extends Collection<V> {
    flatMap<VM>(): Map<VM>;
}

interface Collection<V> {
    value: V; // sprinkle some covariance
    map: Map<V>;
    concat(): Collection<unknown>;
    flatMap(): Collection<V>;
    flatMap<VM>(): Collection<VM>;
}

// Comment out and it works like in 5.2
interface Keyed extends Collection<number> {
    concat(): Keyed;
}

type R = Map<never> extends Collection<infer V> ? V : "NO";

const r = null! as R;
const t: "NO" = r;

🙁 Actual behavior

R is unknown. Removing Keyed makes R "NO", even though Keyed is unused otherwise.

🙂 Expected behavior

Not really sure. I'd settle for the stable 5.2 behavior, which is for R to be "NO" although that also seems wrong (Why doesn't Map<never> extends Collection? If we remove flatMap(): Collection<V> from Collection then Map<never> extends Collection. This seems like the correct behavior.)

Additional information about the issue

No response

[RyanCavanaugh]

Bisects to #53396, cc @ahejlsberg . Trying to find a more direct repro that involves only a single assignability check, but I suspect the self-reference in Keyed is a necessary component.

Edit to add: Adding variance annotations doesn't help.

[ahejlsberg]

Several interesting things going on here. The following

declare let c: Collection<never>;
declare let m: Map<never>;
c = m;  // Error

reports the error

Type 'Map<never>' is not assignable to type 'Collection<never>'.
  The types of 'flatMap().value' are incompatible between these types.
    Type 'any' is not assignable to type 'never'.(2322)

That's surprising, particularly since the interface Map<V> extends Collection<V> declaration doesn't have any errors and for any other V the two are assignable. The root of the problem here is erasure of type parameters. When relating the flatMap members, we erase the VM type parameter to any. Then, because Map<V> doesn't declare a non-generic overload of flatMap, we end up relating flatMap(): Collection<any> to flatMap(): Collection<never> and we then run into any not being assignable to never.

Now, there's something very fishy about the flatMap overloads in the first place--how, without actually having a parameter of type VM, can the generic overload know what to return? And, clearly, V and VM can be distinct and different types. Then, in the derived Map<V>, the non-generic overload has disappeared, making matters even more inconsistent. So, the declarations don't make sense, but because our overload checking is rather weak, we report no errors.

Anyway, the R type in the example really ought to resolve to never, but it doesn't due to the above.

But why does R sometimes resolve to unknown? The issue there comes up when we infer from Map<never> to Collection<V> in the conditional type. The generic flatMap<VM>(): Map<VM> in Map<never> gets erased to flatMap(): Map<unknown> from which we then infer to the non-generic flatMap(): Collection<V>. But, due to the logic in #53396, this inference only happens when Map<unknown> has a lower type ID than Map<never>. And that in turn depends on whether the Keyed interface declaration has been checked first (because it materializes Map<unknown> during the checking).

I'm going to think about possible fixes. We should probably discuss in our next design meeting.