Unexpected "property is not assignable to type 'undefined'" on dynamic assignment #61409

Activity

1. nmain commented on Mar 12, 2025

   

   Nicholai Main (nmain)

   on Mar 12, 2025

   More actions

   This is intended behavior, and was changed in #30769 and documented as a breaking change in https://github.com/microsoft/TypeScript/wiki/Breaking-Changes#fixes-to-unsound-writes-to-indexed-access-types. The compiler only allows it when it can prove the key type is just the unit "a" and not "a" | "b".

   👍React with 👍1Reacted by Martin Johns
2. DimaIT commented on Mar 12, 2025

   

   Dzmitry Tolpekin (DimaIT)

   on Mar 12, 2025

   Last edited by DimaIT

   Author

   More actions

   An error would be expected if we try to set the value of potentially different type, as described in the link you've provided.
   But in my example value types match, therefore it's not clear to me why such behavior is expected.

   interface A {
       a?: number;
       b?: string;
   }
   
   const original: A = {};
   const target: A = {};
   
   let prop = "a" as "a" | "b";
   target[prop] = 10; // Error - expected
   target[prop] = "str"; // Error - expected
   target[prop] = original[prop]; // Error - why?

   UPD:
   Also the issue is gone if we do exact same assignment, only inside a generic function:

   function write<K extends keyof A>(arg: A, key: K, value: A[K]): void {
       arg[key] = value;
   }
   write(target, prop, original[prop]); // now it works
3. MartinJohns commented on Mar 12, 2025

   

   Martin Johns (MartinJohns)

   on Mar 12, 2025

   Contributor

   More actions

   Also the issue is gone if we do exact same assignment, only inside a generic function:

   Be aware that this is (intentionally) unsound and allows invalid assignments: write<"a" | "b">({}, "a", "abc")
4. nmain commented on Mar 12, 2025

   

   Nicholai Main (nmain)

   on Mar 12, 2025

   More actions

   But in my example...

   There's quite a bit of explanation in #30769, and in the many linked PRs from that, that explain this all in more detail.

   Also the issue is gone if...

   I'm not certain, but I believe this is a separate (although somewhat related) soundness issue. The type A[K] is evaluated as if it were a read, but then is allowed for a property write. Property writes are sometimes treated covariantly when they shouldn't be.

   The existence of one soundness hole does not imply that all soundness should be removed.

   👍React with 👍1Reacted by Dzmitry Tolpekin
5. DimaIT commented on Mar 12, 2025

   

   Dzmitry Tolpekin (DimaIT)

   on Mar 12, 2025

   Author

   More actions

   There are some nice explanations indeed:

   As human beings, we know if the key is the same, so will the type retrieved, regardless of what types are involved, but this doesn’t automatically follow from the compiler’s perspective unless the compiler is explicitly programmed to track it.

   Even a workaround was proposed, but not implemented.
6. Dzmitry Tolpekin (DimaIT)

   closed this as a duplicateof Cannot assign property to same type with generic key #32693 on Mar 12, 2025
7. microsoft

   locked as resolved and limited conversation to collaborators on Oct 22, 2025