Design Meeting Notes, 9/6/2024

[DanielRosenwasser]

Consistency for Computed Properties in Classes

#59860

• Working on making computed properties work consistently between source files and declaration files.
• In object literals, anything goes.
• In classes, they do not behave the same.
  • We error if a computed property doesn't resolve to a specific well-known symbol, unique symbol, or literal type.
  • For computed methods.... we say nothing?
• Want to make classes consistent with object literals.
• This PR just fixes computed
• Downsides?
  • It breaks code (obviously).
  • Still need to run on top codebases.
• Does this just change classes, or also interfaces?
  • Just classes.
• Do we really need to adopt the behavior where it produces index signatures?
  • It's the only thing that has consistent behavior for isolated declarations?
• What if you have multiple computed properties with different types?
  • Just use the union of the types in a single index signature, but not necessarily the best behavior we could do - would be a follow up.
  • Can have multiple index signatures these days, so maybe we just produce multiple index signatures.
• What happens if you don't know the type?
  • Just create a string index signature right now so that it's consistent with object types.
• Do you really want these index signatutes?
  • In the object literal case, there is no way to add an index signature to the object literal.
  • But a class is sort of used as a hybrid between a JavaScript value declaration and a TypeScript type.
• We like consistency, but feel a little shaky about just introducing index signatures (the follow-up).
  • Can do that behavior, but can still error possibly?

Node, Type, and Signature monomorphization

• #59190
• #59191
• #59192
• Moves non-monomorphic properties to a data grab-bag
  • Causes v8 to optimize this correctly
• getters/setters in the prototype chain expose the data. properties for compatibility
  • You can put arbitrarily many getters in the same chain for convenience since they're 1:1
  • We still go through these in this PR and see wins; we could go to .data instead and likely get faster?
• Big big big speedup, slightly more memory usage
• Concern: all these properties show up in a debugger
  • API consumers will see all these properties too; implications for in
  • Can we provide API users with a more-specific facade?
    • Work in progress, numbers on this approach soon
• Conclusion: Check on Ron's version and merge whatever looks best overall