Description
Strict Class Initialization with Computed Properties
- PR closes a bunch of bugs.
- In
strictClassInitialization
, we check for "regular" properties, but not properties declared as comuted properties. - Why is this different from other narrowings?
- Well we have to specifically create a "reference" to understand how a computed
- Still adding to control flow graph.
- Need some eyes before we merge.
Issues with Parameters
and ReturnType
-
MethodKeys extends Methods<T>
->T
with only its methodsT[Method]
took us too long to expand, and said "maybe!" and let it pass through.- Now we can tell that this is really an invalid option.
-
We "narrow"
Methods
based on some criteria, but then try to index back intoT
with it, and don't have any way to surface that criteria. -
Can use... a type helper called
Cast
😬type Cast<T, U> = T extends U ? T : T & U;
-
How often does this come up?
- Mongoose types got hit, their conclusion was the type was wrong.
-
Would be nice if we had a first-class primitive to handle this.
- Higher order encoding?
- Maybe just a new primitive.
-
Aside: all of this is very hard to reason about!
-
The
Maybe
behavior seems like the wrong thing.- Most upsetting thing about this is not the change in behavior, it's that we didn't do this before and people accidentally took a dependency.
satisfies
Operator (Contextually Typed-by and Assignable-to Operator)
-
Need to write down the 2-3 use-cases.
-
Details like freshness, excess property checking, etc.
-
Until then, hold off on the PR, but we want to use it to play with different behavior.
-
Had a lot of syntax discussions, but the semantics are going to drive the syntax.
-
Maybe use a different keyword to ensure we're not tying any preconceived ideas?
-
What if you could write
const
anywhere in anas
and it inferred the const-y version of the expression type? Then you could writetype Validate<C, T extends C> = T; { x: 0 } as Validate<Point2D, const>;