Conditional type inside function resolves differently than at top-level

[webstrand]

Bug Report

🔎 Search Terms

regression conditional type inside function behaves difference

🕗 Version & Regression Information

• This changed between versions 4.2.3 and 4.3.5

⏯ Playground Link

Playground link

💻 Code

{
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // ok
}

function test() {
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // error
}

🙁 Actual behavior

The conditional type resolves differently in global vs local scope.

🙂 Expected behavior

Both should resolve the same way, preferably false in both cases.

Additional Details

This seems to have something to do with the way typescript compares aliases, wrapping one of the Record types in Omit<Record<...>, never> causes the comparison to behave normally

Playground Link

function test() {
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // error
}

function test2() {
  type A = Omit<Record<string, number>, never>
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // ok
}

function test3() {
  type A = Record<string, number>;
  type B = Omit<Record<'a' | 'b', number>, never>
  const x: A extends B ? true : false = false; // ok
}

function test4() {
  type A = Omit<Record<string, number>, never>;
  type B = Omit<Record<'a' | 'b', number>, never>
  const x: A extends B ? true : false = false; // error
}

[webstrand]

Additionally, prior to 4.2, typescript permitted Record<string, number> to be assignable to Record<"a" | "b", number> regardless of scope. (Only when comparing Record alias types)

{
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // error, A is assignable to B
}

So 4.2 is the only version that is correct. This may be a false regression?

[ahejlsberg]

This is a particularly unfortunate manifestation of a known issue related to variance measurement.

For Record<K, T> we measure K to be contravariant, which is correct for all types but string, number, and symbol. Those types resolve to index signatures, and index signatures relate differently than regular properties (they're more like optional properties). According to variance, Record<string, number> is a subtype of Record<'a' | 'b', number> because string is a supertype of 'a' | 'b'. However, when related structurally { [x: string]: number } is a supertype of { a: number, b: number }.

To make up for this discrepancy we mark type parameters that occur in the key position of mapped types as having "unreliable" variance, which causes us to relate types structurally when they appear unrelated according to variance.

The net effect is:

declare let aa: { [x: string]: number }
declare let bb: { a: number, b: number }

aa = bb;  // Ok
bb = aa;  // Error

declare let ar: Record<string, number>;
declare let br: Record<'a' | 'b', number>;

ar = br;  // Ok (related structurally because of "unreliable" marker)
br = ar;  // Ok (permitted by variance, but error structurally)

We could fix this my marking type parameters that occur in the key position of mapped types as "unmeasurable", which would cause us to always relate structurally. But (a) this has negative performance impact, and (b) it would technically be a breaking change because undoubtedly code exists that depends on the current behavior. I'm pretty sure we've already tried and rejected this remedy.

Returning to the original example in this issue, the global scope A and B types have new alias symbols associated with them and therefore appear not to be instantiations of the same generic type. Thus we relate them structurally. However, the local A and B types aren't given new alias symbols (for unrelated reasons) and therefore appear to both be instantiations of Record<K, T>. Thus we relate them according to variance.

The behavior changed in 4.2 because that's when we introduced the ability to re-alias type alias instantiations.

[fatcerberus]

Wow… it feels so wrong that an undocumented internal implementation detail like that should affect assignability. Not that that doesn’t happen elsewhere (variance measurement being what it is), but this one is particularly hard to come up with theoretical justification for without popping the hood of the compiler.

[fatcerberus]

it would technically be a breaking change because undoubtedly code exists that depends on the current behavior.

For what it's worth, I wouldn't be caught dead intentionally relying on any behavior that can best be summed up as "A is unsoundly assignable to B, but only sometimes, depending on internal compiler implementation details", where just moving the code around could break it. If it turned out my code was accidentally dependent on that behavior and a documented bug fix broke it, I wouldn't even be upset.

[ahejlsberg]

I mentioned this is already a known issue. For reference, it was first reported in #29698. We even have a test to show the inconsistency, introduced in #30416. That PR first attempted to mark all mapped types as "unmeasurable", but then we backed off, I think because there were too many DT breaks. We may have to try that again.

@weswigham Thoughts?

[fatcerberus]

No worries, I understand it's a design limitation; it's not really the unsoundness that bothers me but moreso that I'm trying to figure out the rationale for the discrepency below so I can try to invent a theoretical explanation for it that doesn't involve popping the hood 😉

the global scope A and B types have new alias symbols associated with them and therefore appear not to be instantiations of the same generic type. Thus we relate them structurally. However, the local A and B types aren't given new alias symbols (for unrelated reasons) and therefore appear to both be instantiations of Record<K, T>. Thus we relate them according to variance.

edit: I just realized this probably only affects the case where you're creating type aliases for generic instantiations, and things directly typed as Records (or whatever else) will relate more consistently (i.e. always variance-based). That's not so bad, in that case.