Iterable vs. array-like for the [] syntax about proposal-pattern-matching HOT 7 CLOSED

Thanks, that clears it up a bit - so you're suggesting that the [ ] syntax pivot on iterability and not just arraylike-ness - and since strings are both arraylike and iterable, they don't impact this issue's topic at all.

from proposal-pattern-matching.

I will include some text around the difficulty of doing this. I think it's possible but it's potentially hard to implement and potentially difficult to think through side effects. Consider:

match (iterable) {
  [ x, y, z ]: // iterable .next called 4 times (last to confirm done: true)
  [ x, y ]: // either iterable rewinds, or more likely, previous values for this iterator are cached...
}

from proposal-pattern-matching.

Hmm, so it wouldn't work obviously nicely on one-shot iterators, I see. I was hoping it would be analogous to

const [x, y, z] = iterable; // does this throw or not? if so, try next line:
const [x2, y2] = iterable;

but yeah, it's not that simple.

from proposal-pattern-matching.

If match takes an iterable, how would you match both a string literal and an array in the same construct?

from proposal-pattern-matching.

By putting the string first before the iterable pattern.

from proposal-pattern-matching.

match (iterable) {
  'foo': …
  [...]: …
}

What if I want to pass ['f', 'o', 'o']? Wouldn't that match the first pattern?

from proposal-pattern-matching.

No, not per the proposal in the readme.

from proposal-pattern-matching.