Why doesn't Array.from() pass the array to the mapFn?

[Ben Katz]

I have a couple ideas why:

1. It discourages separation of concerns - cloning/filtering/mapping...
2. Iterables can change mid iteration. Better to make the clone process as atomic as possible. 


> On 4 May 2017, at 1:12, the kojoman <kojoman at gmail.com> wrote:
> 
> Thanks Jordan, filter was, of course, what I was looking for. Just got carried away, when I saw it had a mapFn as an option and thought I could use that somehow to cut a corner. 
> By the way, and kind of off topic, why is mutating a list mid-iteration bad news? I'm just curious, and obviously not a computer engineer. 
> 
> ons 3 maj 2017 kl 23:37 skrev Jordan Harband <ljharb at gmail.com>:
>> Good point :-) i guess as the destination index it makes sense, altho i've always thought of it as the source index.
>> 
>>> On Wed, May 3, 2017 at 12:58 PM, T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:
>>>> On Wed, May 3, 2017 at 7:35 PM, Jordan Harband <ljharb at gmail.com> wrote:
>>>> (an index in Array.from wouldn't make sense, because Array.from takes an iterable *or* an arraylike - and only an arraylike would be guaranteed to have an index, or even a "list" at all)
>>> 
>>> And yet, [it provides one](https://tc39.github.io/ecma262/#sec-array.from). It's the index that will be used to set the array entry from the result. It's only the third argument (the source object) that `Array.from` doesn't include.
>>> 
>>> -- T.J. Crowder
>> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170504/588c3ebf/attachment-0001.html>