Surprising difference in nested calls inference from contextual type #56714
Labels
Help Wanted
You can do this
Possible Improvement
The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone
π Search Terms
inference nested contextual type reverse mapped type parameter
π Version & Regression Information
β― Playground Link
https://www.typescriptlang.org/play?ts=5.4.0-dev.20231208#code/C4TwDgpgBAggxsA9gJwEoQGYB4AqBJAOzAFdgA+KAXigG8AoKKOZCAQ2AgH4AuKACgCWRUr3zDgASioUAbogEATANx0AviroKIcADasWUDMQIIBiAoeSIAtgGEW7CLkIlyfBkwcdeg8aJekUpSy8goANHQSvPBIaJjO4mQaWrr60EYmwGYWAM4QwMRgAIxYHjgxKDlQEAAeHAQKVehwKApYOcDIQgDmYbAIKOjYBBAyEMhkZBFkgtZgOjm89IysA8g5PLQejADaANJQQlAA1hAgiBhQ5Ws5ALqiFev7tyqM6mpRV485Gi0EHVAWDliDpgEUqFA8gVinxllBVrFFltGIwAO4CYAACwCwF4GCsdi8ED4vlcvA6XQI3SCFBoqgkERRUHRWMQpBxeIJ9jYHBJNNo9MZUFUEXpGiBILBKgA9NKoAA9Th0TTaPQGDKmcyQ-KFABMpUY10R1TqEAaTW0rXanR6fUeQywIzGEymdBmAjmCyW8JumyNlWFn3961+5gBEtBuohUL1sI8CMqS22zIx2L8lhs3McJKEZMhNqp-LpDOTLMxbOAHIzhJ5xL4RcFHhFH3FEGBkZlcsVdCAA
π» Code
π Actual behavior
The only difference between those 2 calls is that
TActors
of the outersetup
call is either iterated over (withIdentity
-like mapped type) or not.Yet when this "noop" iteration is involved we infer the constraint of the
TInput
parameter in the nestedfromCreate
call. When the iteration is not involved then we infernever
.π Expected behavior
I'd expect both of those calls to behave identically.
Additional information about the issue
ActorRef<never>
whereas with the iteration it'sTActors["withoutInput"]
inferTypes
usingInferencePriority.ReturnType
from the instantiatedcontextualType
but with the iteration we getsilentNeverType
forTActors
and thus alsosilentNeverType
for the whole indexed access. AsilentNeverType
is non-inferrableActorRef<never>
gets inferred) and the other one is not (so it defaults to its constraint).It might not be worth fixing this. I figured out that it might still be interesting to raise this. Maybe a rule similar to the one introduced here could be introduced somewhere? A more specific type (depending on the variance of the type parameter) could be picked up from the constraint type and the type inferred using
InferencePriority.ReturnType
. I'm not sure if that would work in practice though - just thinking out loud while writing, without giving this more thought πThe text was updated successfully, but these errors were encountered: