Description
Broken Method Calls on Unions
- Added a new signature to
every
that takes a type predicate. - Is narrowing with
every
more important? Or isevery
on 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
every
overload. - 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 getsBuffer
and 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
as
or 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
get
operator. - The real
get
doesn't just do dots, they also indexed accesses.- So the naive version of this is wrong.
- Should you just have a
split
operator?
- 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
void
parameters become optional, want to funnelvoid
toresolve
from the outside onPromise
s.- Idea is
await
in certain contexts gets ignored; so just make the contextual type for the expression toawait
Promise<void>
. - Conclusion: want to experiment with something more general that starts out with
void
in the top-level, gets transformed in theawait
.