Why does this proposal not use the iterator protocol?

[saambarati]

It feels weird to me reading this proposal that it iterates over arrays the old school way. Is there a discussion around this? I see there was some discussion around isConcatSpreadable. But was there ever serious consideration in making this just use the iterator protocol?

It seems like having a generic flatMap that operates over things that are iterable would be useful. It feels a bit constrained to me to limit this API to things with a ".length" and indexed properties.

[ljharb]

Strings are iterable, it would be super surprising and weird and buggy to flatten strings into arrays of code points.

[bakkot]

See #8.

[saambarati]

@ljharb The example you note is not surprising at all. It’s actuallt exactly what I’d expect.

@bakkot Thanks I will read through that thread

[saambarati]

@ljharb I can see how flattening a string may be confusing, as an example from the other thread: [“foo”, [“bar, “baz”]] Code points here would be intuitively unexpected, I agree. But I also feel like I should be able to flatten strings in some instances. I see how deciding semantics here is tricky.

[michaelficarra]

See also #34. If you want the iteration protocol behaviour, you can simply

a.flatMap(xs => [...xs])

or if you don't know that they're all iterable,

a.flatMap(xs => Symbol.iterator in xs ? [...xs] : xs)

We wouldn't have this flexibility the other way around if we had chosen the iteration protocol. Besides, I really like the consistency of X.prototype.flatMap only flattening Xs that we agreed upon at the September 2017 meeting.