-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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>->Twith 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"
Methodsbased on some criteria, but then try to index back intoTwith 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
Maybebehavior 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
constanywhere in anasand 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>;