Design Meeting Notes, 8/4/2017
DanielRosenwasser opened this issue · 1 comments
DanielRosenwasser commented
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.
masaeedu commented
Well, so is await and .then in the first place.
Sure, but the problem is that you'll either:
- Solve this problem over and over again (how do I refer to the return type of a function type? how do I refer to the value type of an array type? how do I refer to the
Foo
type of aBar<Foo>
type?), or - Leave everyone who doesn't have a broadly applicable enough instance of the same problem in the lurch
We can't change how await
or Promises work, because TypeScript has to describe JS. We can however change the kinds of concepts TypeScript uses to describe JS.