Type inference in index type assignment is skipped

[sparr]

TypeScript Version: 3.8.3

Search Terms: index indexed type assignment initialize initializer initialization inference object narrow narrowing assertion

Code

type One = { name: string; };
type Many = Array<One>;
type OneOrMany = One | Many;

var one: OneOrMany = { name: "sam" };
one.name = "pat"
var many: OneOrMany = [{ name: "sam" },{ name: "ash" }];
many[0].name = "pat"
// all is well here

interface OOMDict { [key: string]: OneOrMany; }
var oomdict2: OOMDict = {};
oomdict2.one = { name: "sam" };
oomdict2.one.name = "pat";
oomdict2.many = [{ name: "sam" }, { name: "ash" }];
oomdict2.many[0].name = "pat";
// all is well here

// testing resolution within an index type initializer
var oomdict: OOMDict = { one: { name: "sam" }, many: [{ name: "sam" }, { name: "ash" }] };
oomdict.one.name = "pat";
// ERROR: Property 'name' does not exist on type 'OneOrMany'.
// ERROR: Property 'name' does not exist on type 'Many'.(2339)
oomdict.many[0].name = "pat";
// ERROR: Element implicitly has an 'any' type because expression of type '0' can't be used to index type 'OneOrMany'.
// ERROR: Property '0' does not exist on type 'OneOrMany'.(7053)

Expected behavior: Initialization / assignment of an OOMDict object effects type inference on its OneOrMany values identically to initialization or assignment of a OneOrMany variable.

Actual behavior: Values in an OOMDict either do not narrow based on their contents and type inference (oomdict.many does not narrow from OneOrMany to Many) or they narrow to the wrong specific type (oomdict.one narrows from OneOfMany to Many instead of One).

Playground Link: https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=56&pc=1#code/PTAECMEMGcEsGNQBcCeAHAptAUKzoB5AOw1AF5QBvUIyAWwwC5RokAnWIgcwG5QBfHrnSkAspCIpyoAIJs2kFAB5iGAHxC8pVQTbjJ01aAA+ofSiHYQyLEk5dQbLAHsANgFc7zoqGcAzZAALbRJdc2QRCBgMABNfH3hvJAwiJBwAN0g2eKZCUL0JKQpqWgZmACJoenKBIWtIJCDYaFA0Z05G71JAmFBIVydIGKlaeWcAd1jQPzZnOjyMMMLkZwWo6CnvUFg00ETUlLSAGj6-ZOznbM5WDCHfAKRgvugNtmS4nQKDLT7wZ3SMNgugA6UqkCjlNANcrYTLZOiFZifcIUADaJXouUq1QEJwxZVA5RggRq-AAunUwAiDD0WqNZpM4jM5gslt9VuEoBs4lsdi19slUjhqShUQAGMmgzHSSHQ7Ai4EItAACgAHuQ1KBVQBKKxgfqubYtSauVzYPU2Vj2RwuDxeHz+IIhRZfKQ-cY7QKcPo+TgxDDqrTYDoYNh+SDwbQEUQAEQQjWoqIA1hgUMxWBxuGSkflzHx+LCsr45jF4wAmJHRuPwRrFQRAkvl4FdUDWFvNUBJogTHxIVbgUiQVmuvqNR4dtodbCgGfSfFYqp0UmUp3POBcIgMVI0LIMzYkaazebI5Z9hYNuilmtl5skKUMGVQpDlITORvXxXLawio2d7vjXt+0HYdwgaJoWknVJp1nNF5wqRdSTxHcCSJaASQECkLUeQcXlgDct0aekJimH9mWPXNTw5QoLyvJAbxFcVJTBR9oRXA1fxNM0sNsa0nGgNxPFgLYPXHHwJG2Ih-UDSJOB2WB+lgAAvUNCwud8kErWN4znHJmDgwkENxUARWYdFkIXHF+CQsEKmJUkyVqLCvRaGB103Q5QFpUAADkCAAFR3MZGVXH5HTfS941vUhLmLCKa0-SQLT+R4+icFg7FNCJMBcloTwMMDxwg9pUhOdxJKwWAFHAVwUBoyKQWYiEnxfC0AFEACV2oIdrmAABVmTA3ikAByMFhtAGJnCwGhnEaANmk6XtImGvKUGG4E2s67q+oG0NUFAUbMXGybpu7ObVQW+IstIYbzHW5UywAZkegBOXVrG81ZYH9IdxkCN1nNAcZnHcVw4iI8YVjMQoTicBFZO4EDlmB0G4jA1xblYCBgLoS5SA2Ig4Gq0g6GaAcenSIS2Dq+KGIle9wUJZqVw6rqetAVqMYI7Y6DQVwEB2GrPN6cThsKcafgHeBIHcDZQADNA+LgLZHR+YaxXG6WiGGxoB1AWWpjPP0A2ug7VvWza2Z25xBv29XjqmulZvli6sa2NXzeBZUAHYxQAVke96wBkYy8YAWgVjAaymcNYA8NKzwhjaLREwI1zw9yhUPFkJFm4ILnAAArKOkFU2LaMezTq1rKh6zhFgQbYSMq+04pdKocz4Msk4TNAMybIM7uO4H1D0PJRy-Bi5UMcaFMpG9fj3CbjBtSoaCZ3Civk1TByKEX5ft5QClWzAVCkckGp89IE7oG1xpglcNAaaQR6ooZljn1fdTX7ppjpSa1iFpFykFDLMNgOVfj-EBBaWW1ohx+DKjWISPhJ7ZEyPzGIDRkESRuHcVW6BrTYUIFWbSfIMCuD8Ngf08BXBZFIAgogSCtjoO+g0DAypN7xhbjWbUzB0jtBiNgfYbt1IABYdJdD0p3QeS4jK937piLusirLD0UYSOyGFHIsMwckDhYjtSWCAA

Related Issues: #1706 #5089

[RyanCavanaugh]

I recall there being some reason we don't narrow based on the initializer, but I don't recall at the moment. We should look into it again to see if something's practical