Defer indexed access type resolution

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types in situations where we were previously too eager.

Fixes#17456.

[Marin Marinov (gcnew)]

The immediate issue is resolved, however I don't think that's the complete fix. Currently, indexing errors are not properly reported:

typeE<T>={true: 'true'}[ObjectHasKey<T,'1'>]// should error, `false` not handledtypeErrorExample=E<[string]>// any :/

Here's the complete set of tests I'm using:

typeStringContains<Sextendsstring,Lextendsstring>=({[KinS]: 'true'}&{[key: string]: 'false'})[L]typeObjectHasKey<O,Lextendsstring>=StringContains<keyofO,L>typeA<T>=ObjectHasKey<T,'0'>typeB=ObjectHasKey<[string,number],'1'>// "true"typeC=ObjectHasKey<[string,number],'2'>// "false"typeD=A<[string]>// "true"// should be an error, `false` not handledtypeE<T>={true: 'true'}[ObjectHasKey<T,'1'>]typeJuxtapose<T>=({true: 'otherwise'}&{[k: string]: 'true'})[ObjectHasKey<T,'1'>]// "otherwise" is missingtypeDeepError<T>={true: 'true'}[Juxtapose<T>]// should be OKtypeDeepOK<T>={true: 'true',otherwise: 'false'}[Juxtapose<T>]

[Anders Hejlsberg (ahejlsberg)]

Marin Marinov (@gcnew) With latest commits we can now properly reason about higher-order types of the form (T & { [x: string]: D })[K]. That's probably as far as we can go along this path, we're definitely at the outer edges of what this was designed for. 😃

[Marin Marinov (gcnew)]

Thank you!

I'm definitely aware we are on the edge here. I've been pondering whether it is more correct to leave the behaviour as is in master, or fix it. On the one hand, the & operator distributes the & operation on colliding properties, which means that { true: true } & { [key: string]: string } should transform to { true: true & string } & { [key: string]: string }. The possible property types thus are (true & string) | string, reducible to just string (the status quo). On the other hand, that's not a faithful representation of what might happen at runtime. Expression level indexing also picks the type of the property if such a property exists.

All in all, I'm leaning towards the second option, the one implemented by this PR. It's unfortunate that & has the strange semantics it has and the complications they carry with them.

[kiara (KiaraGrouwstra)]

{ true: true } & { [key: string]: string } should transform to { true: true & string } & { [key: string]: string }

Would this PR break trying to use property access to grab just true from this?

[Marin Marinov (gcnew)]

@tycho01 As implemented in this PR, indexing will return just true if the key exists.

I was making an argument that the & operator is somewhat inconsistent and was wondering whether the current (the one in master) behaviour is more correct given the semantics & has.

[kiara (KiaraGrouwstra)]

Marin Marinov (@gcnew): Yeah, I'll admit it's hard to foresee. Hopefully the test harness will help find out...

[Daniel Rosenwasser (DanielRosenwasser)]

I mentioned in person that using TypeFlags.Index requires a bit of implicit knowledge. Specifically, such types will only even exist when a lookup type can't operate eagerly. In other words, in keyof T, T must be a type variable to even have something with TypeFlags.Index. An assertion about that somewhere would be helpful, but a long-term way of documenting that would potentially go farther.

Otherwise, the changes seem good to me. I don't see the above being a blocker.

[Anders Hejlsberg (ahejlsberg)]

Marin Marinov (@gcnew) @tycho01 The changes related to transforming a mapped type (T & U & { [x: string]: D })[K] into (T & U)[K] | D more accurately reflect what actually happens when type checking a member access. Given a member access obj.x, where obj is an intersection type, an index signature in the type of obj comes into effect only if none of the constituent types have a member x.