You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
Bindings introduced by destructuring a type annotation should behave as
annotations themselves. That is, `p` in `var {p}: {p: T}` should constrain any
subsequent write to be a subtype of `T`.
This logic works today by wrapping the binding in an AnnotT using BecomeT
internally, which works for most cases. However, since BecomeT performs
unification, it is necessary that its lower bound be resolve once and exactly
once.
The once-and-exactly-once invariant is broken by union-like types when combined
with the destructuring operation. Consider the following example:
```
var {p}: {p:string}|{p:number} = ...
```
When evaluating this variable declaration, we emit the following constraints:
1. {p:string}|{p:number} -> GetPropT ('p', T)
2. T -> BecomeT T'
3. P = T'
Constraint (1) is processed by splitting the lower bound, which turns into two
separate constraints `string -> T` and `number -> T`. Since `T` resolves twice,
the `BecomeT` constraint misbehaves and we see a spurious error that `number` is
not compatible with `string`.
This diff deals with the above by handling union-like types specially in the
`DestructuringT` use type.
Fixes#183Fixes#2198Fixes#2220Fixes#4077Fixes#4270Fixes#5461Fixes#5745Fixes#6408
Reviewed By: panagosg7
Differential Revision: D15457398
fbshipit-source-id: 22c9aba1e1df475c73b36a92bdf7ff5cf57504a6
Here is an example with a redux reducer:
This code:
Produces this error:
see in Try Flow
But, if I move destructuring to the function body instead of function declaration:
see in Try FLow
The text was updated successfully, but these errors were encountered: