-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Description
Broken Method Calls on Unions
- Added a new signature to
everythat takes a type predicate. - Is narrowing with
everymore important? Or iseveryon unions more important? - What if we had a way of saying every type is a predicate for
value is unknown. - Feels bad, but lots of people have asked for the
everyoverload. - Only one complaint since before the beta.
- Conclusion: Probably will not back this change out.
Strict Environment Checks
https://gist.github.com/RyanCavanaugh/702ebd1ca2fc060e58e634b4e30c1c1c
- We had placeholder types as a proposal for a while, but the problem is that anyone who doesn't use placeholder types and just uses a global library can "spoil the pot".
- One big issue: global pollution
- Someone needs
Buffer. Now everyone getsBufferand whatever else comes along.
- Someone needs
- Another: augmentation pollution
- "I need ES6 types like
Map" implies "I need all of ES6" - Placeholder types are good for this, but a lot of this could be solved without placeholder types.
- "I need ES6 types like
- Placeholder types also only worked with separate projects when you need a mixed-environment project.
- Idea:
--strictEnvironment/// <reference lib="es6" />only pulls inlib.es6.types.d.ts(forward declarations for types)- Each file's global scope is determined individually
- What about polyfills? How do you get this to work for people?
- It's sort of intentional - automagic inclusion introduces the pain, you have to opt in.
- It's not quite as non-trivial to construct these environments as we might think - global merging is recursive.
- There's an effort to not transitively include everything, but all of the
/// <reference lib />directives contain more/// <reference lib />. - Conclusion: interested in feedback, need to think more on this.
Key Mapping in Mapped Types
-
The feature ask is "I want to be able to change the name of a property name in a mapped type.
-
Lots of demand, but currently not (easily?) possible today.
- Especially not when generating new keys
-
Idea was maybe let people remap the keys with an
asor something, give users a template-string-like syntaxtype Events<T> = { [K in keyof T as `on${K}Changed`]: (value: T[K]) => void };
-
Also would need some sort of operator to capitalize the first character of a string (e.g.
capitalize K). -
Would eventually be expected as a top-level concatenation type operator.
-
`${"foo"} to ${"bar"}`is"foo to bar" -
Distributive
// "top-left" | "top-center" | "top-right" | "middle-left" ... type Loc = `${"top" | "middle" | "bottom"}-${"left" | "center" | "right"}`;
-
-
Current thinking is these template types work on
-
What about existing code that uses templates?
-
<T extends string>(x: T) => `hello ${x}` // is this 'string' or `hello ${T}`?
-
-
Can we do inference?
- Examples of lodash's
getoperator. - The real
getdoesn't just do dots, they also indexed accesses.- So the naive version of this is wrong.
- Should you just have a
splitoperator?
- Examples of lodash's
-
As you get farther into this, you start to see "this might not be enough"
- You start to want a regex!
-
Out of time, but looking for feedback as this gets prototyped.
Contextually Type Operands of await in a StatementExpression
voidparameters become optional, want to funnelvoidtoresolvefrom the outside onPromises.- Idea is
awaitin certain contexts gets ignored; so just make the contextual type for the expression toawaitPromise<void>. - Conclusion: want to experiment with something more general that starts out with
voidin the top-level, gets transformed in theawait.