Array pattern in destructuring assignment do not typecheck correctly when assigned to an object.

[eyyub]

/* @flow */

var [a, b] = {foo:3, b:'lol'}; // no error
(a : string);
(a : number);
(a : void);
(a : any);
(b : void);
(b : any);

var {p} = [1]; // error, ok
var [a, b] : [number | string] = {foo:3, b:'lol'}; // error due to type annotation, ok

It seems it comes from here.
Maybe in destructuring we should ensure that the type are "compatible"(good english word ?).

[kkirby]

I'm not sure that this is really a bug. Destructing works on objects that are iterators. For example, this is valid JavaScript:

let [a,b] = {
  0:'A',
  1:'B',
  [Symbol.iterator]: function*(){
    yield this['0'];
    yield this['1'];
  }
};
console.log(a,b); // Outputs "A B"

But in your later example, since an object cannot be an array, an error is thrown.

[eyyub]

I see, at least it should be handled as a special case(actually Flow doesn't support this construct) , but IMHO var [a, b] = {foo:3, b:'lol'} should not be allowed.

[samwgoldman]

Yeah, we should be able to constrain the RHS to be an iterable in array destructuring assignments.

[TrySound]

@samwgoldman This became a more relevant problem since hooks were introduced. I convert tuple api to object and miss some places.

[kevinbarabash]

I ran into this today. The current behavior results in variables that are typed as any. I should probably code with type coverage always enabled as that would've detected the issue with my code.

[somewhatabstract]

See also #2612

[gkz]

Fixed in 80ca16f