Closed
Description
satisfies
in JSDoc
- Provides a contextual type in JavaScript without casting or calling a helper function - really nice.
- It's unfortunate that
@type
was used as the original name for JSDoc type assertions.@type
would have been a better syntax for what satisfies does.- Or
@cast
and@satisfies
, and@type
just stays on declarations.
- Or
- But if you know you want to use
satisfies
- How should this work?
- Expression positions the same way
@type
works seems fine. - What about declaration forms? Lots of examples of
@type
or@param
.- We would like
@satisfies
to also work in declaration positions - enforce the assignability check on, and also contextually type, the initializer expression(s?).
- We would like
- Expression positions the same way
Optimizations
- Nice wins from monomorphizing our object types.
- What's next?
- Can still do this for
Signature
,Type
, more.
- Can still do this for
- Experimenting with removing the notion of object allocators (our factory for node classes).
- Slight aside - some difficulties with polymorphism analysis tooling due to esbuild renaming.
- Fixed shapes for
FlowNode
s?- [experiment] Try using consistent shapes for FlowNodes #51585
- Should retry once the deopt tooling is available.
- Also, harder to analyze because they're just object literals.
- Analysis works better when the allocation site consistently comes from a constructor. (e.g.
new Blah()
, etc.)
- Analysis works better when the allocation site consistently comes from a constructor. (e.g.
- We sort of do this with
FlowNode
- But we still set properties after the fact.
- We ran a deopt analysis on the compiler during the meeting. We saw some interesting things.
writeFile
is 16% of the time??? (MS Defender????)- 600ms on
ts
namespace - but it has almost no code???const enum
preservation?- That's nuts.
- Tradeoff for debuggability.
- Suspicious.
emitFlags
is never set, so an|=
can't be immediately optimized.- We could just set it to
0
?
- We could just set it to