Strings **should** be considered as iterables

[zloirock]

With #233, strings are not considered as iterables. It's complete nonsense.

for (const c of 'abc') console.log(c); // => 'a', 'b', 'c'

[...'abc']; // => ['a', 'b', 'c']

'abc'[Symbol.iterator](); // => StringIterator

// etc., many other cases, but only here:

Iterator.from('abc'); // => TypeError

WTF? Yes, making strings iterable was a controversial decision - but since they are already iterable and it's not possible to change it - maybe it's better to stop break the language by adding inconsistencies?

[zloirock]

Furthermore,

Iterator.from(Object('abc')); // => StringIterator

But from ES2015 the behavior of non-modifying methods that can work with primitive wrappers, but can't work with primitives, was changed to accepting primitives, like:

Object.getPrototypeOf('abc'); // => String.prototype (from ES2015)

[michaelficarra]

How do you think flatMap should handle iterable primitives? If it rejects them, it would be inconsistent with your proposed Iterator.from. If it iterates them, it is a potential footgun.

I think we've made the most practical choice here. And the committee usually sides with practicality over consistency. But I was already planning to bring up this decision during the presentation to committee: see item 3.b in this slide.

[bakkot]

I personally would prefer flatMap being inconsistent with Iterator.from over making Iterator.from reject strings.

[zloirock]

I think we've made the most practical choice here.

I'm sure that it's not the most practical choice - inconsistency with the rest cases and breaking the iterables protocol is a more dangerous potential footgun.

I think that .flatMap should handle iterable primitives as iterables.

However, I'm OK if .flatMap will be inconsistent with .from and will reject strings - it's not so painful as Iterator.from case.