Closed
Description
Trailing commas in type argument/parameter lists
- Argument lists and parameter lists both allow a trailing comma.
- Probably more confusing than it helps.
- Revisit if it ever comes up again.
Narrowing from index signature-originating properties
- Control flow analysis currently only operates on the declared types of properties.
- There is no declaration in this case.
- Implementation takes place in
getFlowTypeOfReference
.- When we check if two references are the same, the symbols are the same.
- We agree that this is the behavior that should happen.
- Seems reasonable.
- Would the dynamic names PR be helpful?
- Symbol table would be created during checking.
- Probably stay out of that territory.
- Conclusion: mark as a hard-to-fix bug.
The promised
type
-
With the strictVarianceChecks and other changes, we created a difficult situation for
Promise
/PromiseLike
inference. -
Today, if you have
P.then(() => { if (doSomething()) { return 1 } return Promise.resolve("abc"); })
Currently we end up with
Promise<number | Promise<string>>
. -
There seemed to be some fixes our team was looking at with how we infer between union types.
-
This is difficult because now you have to get into some strange pattern-matching like behavior for unions.
-
What about a negation type?
- Doesn't give you recursive drill-down.
Promised type operator
async function f<T>(x) {
y = await x;
}
- Adds an internal
PromisedType<T>
, which can be described by a new type operator calledpromised T
. - "So this thing is hard-wired to Promise (or PromiseLike)?"
- It's hard-wired to the functionality of
await
.
- It's hard-wired to the functionality of
- Are there type relations described for this type operator?
- Yes, it's on the PR.
- Sounds like there is some strange behavior between how these types relate to each other.
- Current rules seem to imply
S -> promised T
iffS -> T
.- But what about
S = string
andT = Promise<string>
.
- But what about
- Current rules seem to imply
- Difficulty here will be getting "higher order" type relationships correct.
- Also, you have to avoid going off the rails if your
then
s aren't the rightthen
s.- We were already making sure this worked for
await
anyway.
- We were already making sure this worked for
Name bike-shedding
- No
PromiseLike
is ever assignable to thepromise T
.- More like the "eventual" of T.
await T
?
Discussion among community
- People want a more generalized construct.
- This is fairly specialized.
- Well, so is
await
and.then
in the first place.
Array.prototype.concat
exhibits same behavior- Lodash has some problems here too.
- Array-flatten proposal will potentially complicate this.
Conclusion
- Examine type relationships further.
- Bikeshed on the name.
await
,awaited
?- These call attention to the fact that you're working with promises.
- Point is to convey that it is strictly not creating a Promise/PromiseLike instance type.
fulfilled
?- What a gross name.
- Thesaurus suggests "consummated".
Non-null assertion type operator
- Semantics of higher-order relations could be complex.
- Would allowing a
!
intypeof
do what you want?- No.
- Why don't we always carve off
null | undefined
fromT[K]
?- Seems a little strange.
- Not the same as the expression-looking operator.
- Cases where you're using
any
under the hood?- Seems like a lot of those would be handled by constraints of
keyof
.
- Seems like a lot of those would be handled by constraints of
- When do you not want this behavior?
- We'll have to think more about it.
- Seems a little strange.