@typescript-bot perf test faster
@typescript-bot test this
@typescript-bot user test inline
@typescript-bot run dt

Heya@ahejlsberg, I've started to run the abridged perf test suite on this PR atd42e4c2. You can monitor the buildhere.

Update:The results are in!

Heya@ahejlsberg, I've started to run the extended test suite on this PR atd42e4c2. You can monitor the buildhere.

Heya@ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR atd42e4c2. You can monitor the buildhere.

@typescript-bot user test this inline

Heya@ahejlsberg, I've started to run the inline community code test suite on this PR atd42e4c2. You can monitor the buildhere.

Update:The results are in!

@ahejlsberg
The results of the perf run you requested are in!

@ahejlsberg
Great news! no new errors were found between main..refs/pull/47109/merge

I'm kind of surprised at how much of this already works in TS4.5 without these fixes. BothprocessRecord(r1); andprocessRecord(r2); are fine. Sure, theK parameter isn't inferred, but it falls back tokeyof RecordMap which is fine for a distributive object type. Only

processRecord({kind:'n',v:42,f:v=>v.toExponential()});// error

fails outright, and that's just because of unfortunate contextual typing ofv asRecordMap[keyof RecordMap] . In current TS I'd be inclined to fix that with either of these:

processRecord<'n'>({kind:'n',v:42,f:v=>v.toExponential()});// okayprocessRecord({kind:'n',v:42,f:(v:number)=>v.toExponential()});// okay

Am I right in thinking the current fix is mostly helping inference forK succeed here so that these are not necessary? I'm definitely interested in playing around with this. Thanks for working on it!!

Playground link

I'm kind of surprised at how much of this already works in TS4.5 without these fixes.

Yes, the nice thing is that this approach isn't really a new feature. The core capabilities were all there, they just didn't work quite right in a few cases. This in contrast to a whole new feature like existential types, which would be a very complex undertaking.

Am I right in thinking the current fix is mostly helping inference for K succeed here so that these are not necessary?

The PR has three fixes in it. Two of them relate to inference, specifically that we would fail to infer from object literals that contain contextually typed arrow functions.

The third fix relates to indexing non-generic mapped types with generic index types. For example:

typeRecordFuncMap={[PinkeyofRecordMap]:(x:RecordMap[P])=>void};constrecordFuncs:RecordFuncMap={n:n=>n.toFixed(2),s:s=>s.length,b:b=>b ?1 :0,}functioncallRecordFunc<KextendskeyofRecordMap>(rec:UnionRecord<K>){constfn=recordFuncs[rec.kind];// RecordFuncMap[K]fn(rec.v);// Would fail, but works with this PR}

The call incallRecordFunc failed to compile because we transformed typeRecordFuncMap[K] intoRecordFuncMap[typeof RecordMap] by constraint substitution when obtaining what we call the apparent type offn. With the fix in the PR, we instead transformRecordFuncMap[K] into(x: RecordMap[K]) => void.

There are more examples of this pattern in the tests I just added to the PR. Seehere.

Performance is unaffected by this PR and all tests look clean. I think this is ready to merge.

I have run into an oddity that might be related to this PR. Consider the following code:

enumMyEvent{One,Two}typeCallback<T>=(arg:T)=>void;interfaceCallbackTypes{[MyEvent.One]:number[MyEvent.Two]:string}typeCallbacks={[EinMyEvent]:Callback<CallbackTypes[E]>[]};classCallbackContainer{callbacks:Callbacks={[MyEvent.One]:[],[MyEvent.Two]:[]};constructor(){}setListener<EextendsMyEvent>(event:E,callback:Callback<CallbackTypes[E]>){constcallbacks=this.callbacks[event];callbacks.push(callback);// okay}getListeners<EextendsMyEvent>(event:E){returnthis.callbacks[event];}}

Thanks to this PR above code now works! But when I changeconst callbacks = this.callbacks[event] toconst callbacks: Array<Callback<CallbackTypes[E]>> = this.callbacks[event] the compiler throwsType 'Callbacks[E]' is not assignable to type 'Callback<CallbackTypes[E]>[]'. But when (in both versions) examining the type ofcallbacks.push, the Array is typed asArray<Callback<CallbackTypes[E]>>.

Why then, isCallbacks[E] not assignable toCallback<CallbackTypes[E]>[] while in thepush call theCallbacks[E] is automagically converted to that very same typeArray<Callback<CallbackTypes[E]>>?

This PR is linked fromTypeScript 4.6 release notes but the implementation changed soon after it here:#47370