Mapped type property causses different assignability error of compatible subtypes

[dragomirtitian]

Steps to reproduce

interface Table<B> { schema: B; }

interface DerivedTable<S extends DerivedSchema<any, any>> extends Table<S["base"] & S["new"]>{
    readonlySchema: Readonly<S["base"] & S["new"]>
}
type DerivedSchema<B, N> = { base: B; new: N };

interface Base { baseProp: number; }
interface New  { newProp: boolean; }

declare const source: DerivedTable<{ base: Base, new: New }>
const destination: DerivedTable<{ base: Base; new: New & Base }> = source;

Behavior with typescript@5.8

No error

Behavior with tsgo

Error on final line. Reordering the types to have Table be after DerivedTable also gives the same behavior as 5.8

Related to microsoft/TypeScript#62520

[ahejlsberg]

This one is quite involved, but ultimately comes down to a difference in property ordering between Strada and Corsa. This is similar to differences we see because of type ordering. In Strada, properties declared in a derived class are ordered before properties declared in a base class, whereas in Corsa, properties are always ordered according to the source position of their declaration regardless of how they were contributed to a class or interface type. In the repro, this means that readonlySchema is ordered before schema in Strada, whereas Corsa has the opposite ordering when Table is declared before DerivedTable. These ordering differences end up affecting variance computation for DerivedTable such that variance of the S type parameter gets flagged as "unreliable" only when readonlySchema is ordered before schema. The reasons are subtle, but it ultimately comes down to the fact that variance computation is imperfect and sometimes errors on being too conservative.

So, in summary, differences in property ordering cause differences in variance computation which in turn causes the error. Given that variance computation is known to be imperfect, but that we also can't do without the performance gains we get from it, it's not clear there's much we can do here.

[ahejlsberg]

I'm marking this as Type Ordering even though it is technically Property Ordering.

[ahejlsberg]

Here's a simplified example that repros with both tsc and tsgo:

interface DerivedTable<S extends { base: any; new: any }> {
    // Error disappears when these property declarations are reversed
    schema: S["base"] & S["new"]
    readonlySchema: Readonly<S["base"] & S["new"]>
}

interface Base { baseProp: number; }
interface New  { newProp: boolean; }

declare const source: DerivedTable<{ base: Base, new: New }>
const destination: DerivedTable<{ base: Base; new: New & Base }> = source; // Error

I dug a bit deeper into why variance measurement produces different results when the property declarations are reversed. It turns out that we're not properly propagating variance reliability flags in all cases. In the repro above, variance for the type parameter of Readonly is flagged as unreliable, but then in the variance computation for the type parameter of DerivedTable, that flag is propagated only when we resort to a structural check of Readonly<S["base"] & S["new"]>. In other words, when using computed variance to relate instantiations of Readonly<S["base"] & S["new"]> for S as a supertype and subtype, we only propagate the unreliable flag when the relation fails and we resort to a structural check. We really should be propagating the flag in all cases.

It's not a complicated fix, but it may affect checking of existing projects and could have performance implications. I will put up a PR for the old compiler so we can get some data.