Design Meeting Notes, 4/27/2022

[DanielRosenwasser]

Numeric Keys

#48837
#27995

• Really weird that you can index an array with a numeric string literal, but you can't index into an array with `${number}`
• New PR makes this work.
• Also - when you have a mapped type constrained to a tuple type, the constraint becomes number | `${number}`.
• Should we be ensuring round-trippability?
  • Seems like round-trippability doesn't seem like the right thing to ensure the precise semantics anyway.
• Why do mapped types behave differently in the "0-order"?
  • Mapped tuples types iterates over all properties #27995
  • keyof gets evaluated eagerly - we don't keep that information (i.e. whether the key types came from a keyof on an array) around.
  • Could do this if you write the type inline.
    • When does this fall over?
      • When they keyof gets orphaned somewhere else.
  • Likely can't change this at this point?
  • Could enable this with spread types maybe?

Type Parameter Comparability

#48861

• T extends unknown shouldn't be different from T
• Two perspectives
  • On one hand, you want to allow comparison to/from constraints of type parameters because equality can always plausibly be true
  • On the other hand, you really don't want two type parameters to be
• PR: Two types can be compared if their domains of possible values can overlap, but two type parameters cannot be compared unless one extends the other directly or indirectly.
  • Are there breaks?
    • Technically two explicitly constrained "unrelated" type parameters will no longer be related.

Narrowing Type Parameters and unknown

#48576

• Issue: break on generics to {}/object breaks code that does correct narrowing.
  • We would do this contextual narrowing if you wrote T extends {} | null | undefined.
  • Idea - try to narrow from constraint of T and T extends unknown when you have a contextual type that
• Another approach - intersecting in primitives and {} with type parameters some cases.

[ExE-Boss]

For “Numeric Keys”, there’s also #43041.