Skip to content

Design Meeting Notes, 2023-10-27 #56233

Closed
@RyanCavanaugh

Description

@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
    • ???¿??

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions