Repository navigation
Inference is broken on intersection type utilizing polymorphic thisΒ #53970
Description
Activity
- changed the title
[-]Inference is broken on intersection type utilizing polymorphic `this` due to deferred index access resolution[/-][+]Inference is broken on intersection type utilizing polymorphic `this`[/+]on Apr 22, 2023 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)Reacted by Yuriy Bogomolov, Daniel Steigerwald, ecyrbe, StΓ©phane Le Dorze, Andrew M, Tim, Steff, Kasper Peulen, Max Lay, TomΓ‘Ε‘ HorΓ‘Δek and 3 moreSame here, zodios is using this pattern to enable policy based interfaces.
Reacted by Michael Arnaldi, StΓ©phane Le Dorze, Andrew M, Tim and Daniel SteigerwaldSeems like those packages should be added to the RWC test suite maybe, or snippets of them added to the main compiler tests
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.
Reacted by Michael ArnaldiAnders Hejlsberg (@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.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 forAthrough instantiation and, unfortunately, it also means that no inferences are made forAin themap(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 ofmap(typeClass)will still change as in the example above, but inference will infernumberin the final example.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 forAthrough instantiation and, unfortunately, it also means that no inferences are made forAin themap(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 ofmap(typeClass)will still change as in the example above, but inference will infernumberin the final example.This is very problematic we will have to make a backward incompatible change with serious degradation to developer experience, I am honestly in doubt about what feature of TS to trust, this behaviour was even confirmed as intended explicitly by a TS core member in prior issues. This way we don't have any way of safely develop libraries without risk that in 2 releases the TS team decides to change semantic behaviour.
I don't think we need to be this dramatic.
I see this as an opportunnity to clarify TS team stance on HKT.
Community started evolving libraries to take advantage of some HKT features.
As a TS team you have a playground feedback on how community took advantage of it.
Based on this feedback, you Can now either :- officially support a new HKT syntax to address current use cases
- officially announce HKT to not be supported in either way going forward
Clarification is key for us to know if we can leverage some ts features for our use cases.
Again, thank you Anders Hejlsberg (@ahejlsberg) and all ts team for your wonderfull work
I don't think we need to be this dramatic. I see this as an opportunnity to clarify TS team stance on HKT. Community started evolving libraries to take advantage of some HKT features. As a TS team you have a playground feedback on how community took advantage of it. Based on this feedback, you Can now either :
- officially support a new HKT syntax to address current use cases
- officially announce HKT to not be supported in either way going forward
Clarification is key for us to know if we can leverage some ts features for our use cases.
Again, thank you Anders Hejlsberg (@ahejlsberg) and all ts team for your wonderfull work
I mean that was valid behaviour since TS3, I appreciate the work a lot and TS is a fantastic language but unless we can have some sort of guarantee things won't break (unless by mistake) I don't see how to go forward, there are many edge behaviours that are relied upon from the community and this is totally normal for a language without a spec but it only works if we preserve the "strange behaviour" priorly introduced. I can list a number of features that may break with implications to many libraries like for example behaviour of overload selection, many libraries rely on the current ordering and selection algorithm, what if with the ongoing effort to improve inference we end up breaking? I'd always assumed if we ended up there the decision would be not to accept the changes (maybe at the price of perfection) to maximise usability. If instead the policy is "yeah but the behaviour should have really been Y" then I am afraid I can't be sure of most of the TS behaviour, and I am saying this while generally appreciating the efforts and the language, but as as library developer I need to know the boundaries
I understand that esthetically
T<A>looks nicer than(TTypeLambda & { readonly A: A; })["type"], though the latter really is a more precise representation of what was requested inApply. Are there other issues that are caused by this change and not fixed by #54112?We use:
export const f = map(typeClass)
and let it derive the type of
f, with this change the typing offwill be impractical to use and understand from the reader's perspective, the problem seems to be related to potential reduction toneverthat this change aims to preserve, would there be a way of avoiding it in a class of cases whereneveris known to be impossible? I guess that would require being able to express "TypeLambda is an object without the fieldA" ? or maybe a way to force it to reduce the type?In a general sense from a user perspective it isn't necessarily the case that something more precise is always better
Actually I may have found a way:
export interface TypeClass<F> { readonly _F: F } export declare namespace TypeLambda { type _A<T> = "A" extends keyof T ? T["A"] : never } interface TypeLambda { type: unknown } export type Apply<F, A> = F extends TypeLambda ? (F & {A: A})["type"] : { readonly F: F, readonly A: A } export interface T<A> { value: A } export declare const map: <F>(F: TypeClass<F>) => <A, B>(a: Apply<F, A>, f: (a: A) => B) => Apply<F, B> interface TTypeLambda { type: T<TypeLambda._A<this>> } declare const typeClass: TypeClass<TTypeLambda> declare const a: T<number> // const x: <A, B>(a: T<A>, f: (a: A) => B) => T<B> const x = map(typeClass) map(typeClass)(a, (_) => _)
Not sure if this if considered a bug with the new behaviour or this can be used (usage)
It turns out there's a simple way to fix this issue and preserve our old behavior. See latest commits in #54112.
Reacted by Peter Krol, ecyrbe, Michael, Stefano Pigozzi, Michael Arnaldi, Andrew M, Ani Ravi, Dan Minshew, Rae Hill, Olaoluwa (Ola) Mustapha and 2 more- locked as resolved and limited conversation to collaborators
on Oct 22, 2025
Bug Report
π Search Terms
inference, intersection, polymorphic this, deferred index access
π Version & Regression Information
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
Each version including and after 5.1.0-dev.20230315 defers the index access in the
Applytype 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.