Closed
Description
Stricter generic signature checks
- Already did some work in Infer from generic function return types #16072 to perfom type argument inference using the return type of a signature as a target.
- In Contextual generic function types #16305 we added support for signatures to gain type parameters from their contextual types.
- This behavior is more appropriate because it respects the constraints and the universality of each usage of type parameters.
- To follow up with this, we're introducing stricter generic signature checks (Stricter generic signature checks #16368).
- Previously, when relating type parameters, we would erase them with the type
any
. - This was fairly unsafe.
- Previously the following would work, but with Stricter generic signature checks #16368, the following is an error.
type A = <T, U>(x: T, y: U) => [T, U]; type B = <S>(x: S, y: S) => [S, S]; function f(a: A, b: B) { a = b; // Error b = a; // Ok }
- This is kind of a form of unification between the two parameters.
- We infer using the type parameters of the target, as if we were calling the source with the target's parameters.
- In other words, in
a = b
above, it simulates callingb
witha
's parameters.
- In other words, in
- We infer using the type parameters of the target, as if we were calling the source with the target's parameters.
- The caveat is that this logic is only applied to single-signature types.
- Any times you have overloads, it becomes extremely difficult to perform these checks.
- Previously, when relating type parameters, we would erase them with the type
- So the question is: do we put this behind a flag?
- Most errors are good, but it's hard to figure out what to do for some advanced scenarios.
- Get it into
master
and see what we can work with.
Private Slots
Proposal: https://github.com/tc39/proposal-private-fields/ (Permalink)
Repo: https://tc39.github.io/proposal-private-fields/
-
How does this work with existing modifiers?
-
Can we offer a true downlevel translation?
- To ES5?
- No.
- Need weakmaps
- Yes above ES6.
- To ES5?
-
Could give a mangled name in ES5/ES3.
- Has potential problems.
- Proxies, enumeration, etc.
- Proxies and the like don't exist in ES5.
- Best effort might be fine.
- Proxies, enumeration, etc.
- Has potential problems.
-
What about using Symbols in ES6?
- Symbols aren't truly private - can be used by proxies, can be iterated over, etc.
-
Weakmaps make it truly private.
- Are they performant?
- Concerns over the type of GC pressure it may cause.
- Edge is good at this!
- Implementation is that every object has a list of weakmaps so that the lookup is inverted.
- Others not as much at this point in time.
- But will eventually improve!
- But it's all opt-in.
- Is it possible that all users really want is design-time private?
- There are definitely people who've wanted private state.
- Are they performant?
-
P.S.
everyone hates the syntax.we're not big on the syntax -
Completely unrelated
- The proposal breaks JScript 5.8 in IE 8.
- ¯\_(ツ)_/¯
- The proposal breaks JScript 5.8 in IE 8.
-
We'll all need to go over the FAQ more closely on the private state proposal repo.