Inference is broken on intersection type utilizing polymorphic `this`

[0x706b]

Bug Report

🔎 Search Terms

inference, intersection, polymorphic this, deferred index access

🕗 Version & Regression Information

• This changed between versions 5.1.0-dev.20230313 and 5.1.0-dev.20230315

⏯ Playground Link

Playground link with relevant code

💻 Code

export interface TypeLambda {
  readonly A: unknown
}

export interface TypeClass<F extends TypeLambda> {
  readonly _F: F
}

export type Apply<F extends TypeLambda, A> = F extends { readonly type: unknown }
  ? (F & { readonly A: A })['type']
  : { readonly F: F, readonly A: A }

export interface T<A> {
  value: A
}

export interface TTypeLambda extends TypeLambda {
  readonly type: T<this["A"]>
}

export declare const map: <F extends TypeLambda>(F: TypeClass<F>) => <A, B>(a: Apply<F, A>, f: (a: A) => B) => Apply<F, B>

declare const typeClass: TypeClass<TTypeLambda>

declare const a: T<number>

map(typeClass)
// TS 5.0.4:              <A, B>(a: T<A>, f: (a: A) => B) => T<B>
// TS 5.1.0-dev.20230422: <A, B>(a: (TTypeLambda & { readonly A: A; })["type"], f: (a: A) => B) => (TTypeLambda & { readonly A: B; })["type"]

map(typeClass)(a, (_) => _)
                // ^ TS 5.0.4 infers number
                //   TS 5.1.0-dev.20230422 infers unknown

🙁 Actual behavior

Each version including and after 5.1.0-dev.20230315 defers the index access in the Apply type and doesn't allow inference to continue.

🙂 Expected behavior

Inference should continue to work in this case.

After a bit of research, I think that #53098 is the PR that introduced this change.

[mikearnaldi]

This currently breaks the encoding used in @effect/* for HKTs and probably a few other libraries that rely on the same pattern (hotscript, storybook, come to mind)

[ecyrbe]

Same here, zodios is using this pattern to enable policy based interfaces.

[ethanresnick]

Seems like those packages should be added to the RWC test suite maybe, or snippets of them added to the main compiler tests

[jakebailey]

Feel free to send a PR: https://github.com/microsoft/TypeScript-error-deltas

See userTests.

Of course, any PR would include a test case for this.

[ecyrbe]

@ahejlsberg if you find another way to better support HKT, it would also be fine from my perspective.
The need is to be able to pass an utility type to another utility type on type level and still have type constraint available.

[ahejlsberg]

I can confirm that the change in behavior is caused by #53098. We definitely want the deferred resolution implemented by that PR. However, it means that types like (TTypeLambda & { readonly A: A; })["type"] aren't resolved until a non-generic type is substituted for A through instantiation and, unfortunately, it also means that no inferences are made for A in the map(typeClass) invocation.

I think we can implement a targeted fix where, when inferring to types like (TTypeLambda & { readonly A: A; })["type"], we force the resolution that previously happened and then infer to the result of that. This means the type of map(typeClass) will still change as in the example above, but inference will infer number in the final example.