Open
Description
Consistency for Computed Properties in Classes
- 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
- Make AST nodes monomorphic. #59190
- Make types monomorphic #59191
- Make Signature monomorphic #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
- API consumers will see all these properties too; implications for
- Conclusion: Check on Ron's version and merge whatever looks best overall