Design Meeting Notes, 2023-10-27

[RyanCavanaugh]

• More API exposure per our own "bundler" requirements Export internal functions needed by dtsBundler.mjs #52941
  • isDeclarationStatement, isInternalDeclaration
  • nullTransformationContext
    • Why isn't this the behavior under undefined ?
    • Could try
    • Check with Ron
  • isPartOfTypeNode
    • Is this function always correct?
    • Wasn't always, but is now
  • Is stripInternal real now?
    • No.
  • OK for 5.4
• Tuple key remapping Can't remap tuple keys to object keys in mapped types #55762
  • Mapped type over a type parameter constraint to a readonly array of 2-tuples
    • It iterates [a, b] to form a: b
  • Works as expected with & ${number}, but not & number
  • This mapped type hits e.g. indexOf, "0", and the number index signature
    • Correct? Desirable?
    • keyof needs to behave consistently between Array and Arrayish objects
    • But in homomorphic mapped types, the output is still presumably an array, so we don't need to mess with Array methods in that case
    • What we "need" is a different mapped/keyof/whatever syntax to force homomorphism in mapped types
      • But this is a pain, and confusing
  • Why ${number} is needed?
    • This is the bug re: the implied constraint in the as clause
    • You'll still need something to avoid the numeric index signature
• b i v a r i a n c e Class parameter incorrectly treated as bivariant #56225
  • What to do when a type parameter only appears in the test position of a conditional type?
    • We currently (arbitrarily!) treat it as bivariant, for bad and confusing reasons
      • This falls out of the variance measurement process, which doesn't have a good mechanism to relate infer outputs
      • Conditional types are for creating non-varying relations, which wrenches the whole process
  • If this were a lookup type, we could figure out this was covariant, but there's no lookup syntax for a return type
  • Creates further confusion since it's not always obvious if a structural or variance-based relation is occurring
  • Marking all extends T -> unmeasurable on T is fairly catastrophic for performance
    • Also messes with signature relationships
  • Confusing since InstanceOf is covariant on part of the type; even if variance annotations were allowed here, they'd be wrong
  • What to do?
    • Try a PR and see if it's maybe OK now
  • ???¿??