Let me expand on this e-mail a bit more. I am motivated here by our
work on the data parallelism API [1]. As I mentioned in the Boston
meeting, we have been adding alternatives to methods like `from()`
that attempt parallel execution (e.g., `fromPar()`). In general, we
aim for these methods to be as compatible with the existing signatures
as possible.

In the case of `from()`, in a sequential world, one might work around
the lack of an index argument by writing code like:

    var counter = 0;
    var f1 = Int32Array.from(f, e => e + counter++)

rather than

    var f1 = Int32Array.from(f, (e, i) => e + i)

However, this would not work in a parallel setting, since `counter`
would be shared mutable state. Parallel APIs require the second
approach. I would argue the second approach is preferable anyhow, as
it is a more declarative style.

I realize that the spec includes this comment about reusability:

"NOTE The from function is an intentionally generic factory method; it
does not require that its this value be the Array
constructor. Therefore it can be transferred to or inherited by any
other constructors that may be called with a single numeric argument."

There is no particular reason, though, that `from()` cannot include an
index and collection argument, even if the source value is not an
array. In that event, `index` simply represents the number of items
that have been iterated over thus far.



Niko

[1] http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism

On Thu, Dec 05, 2013 at 10:13:58PM -0500, Niko Matsakis wrote:
> The ES6 draft specifies that `map()`, when applied to a typed array,
> yields another instance of that same type. For converting between
> array types, the `from()` method is added:
> 
>     var f1 = new Float32Array();
>     ...
>     var f2 = f1.map(x => x * 2); // Yields Float32Array
>     var i1 = Int32Array.from(f, x => x * 2); // Yields Int32Array
> 
> This is nice. However, there are some small differences between
> the two that I think ought to be aligned.
> 
> In particular, `map` supplies its closure with three arguments: the
> Element (`this[i]`), Index (`i`), and Collection (`this`). The index
> is particularly useful, since you can write things like:
> 
>     var f3 = f1.map((e, i) => e + i)
> 
> It seems that `from` only supplies the E argument though and not the I
> and C. I propose this be changed to match `map()`.
> 
> 
> 
> Niko
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Let me expand on this e-mail a bit more. I am motivated here by our
work on the data parallelism API http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism. As I mentioned in the Boston
meeting, we have been adding alternatives to methods like `from()`
that attempt parallel execution (e.g., `fromPar()`). In general, we
aim for these methods to be as compatible with the existing signatures
as possible.

In the case of `from()`, in a sequential world, one might work around
the lack of an index argument by writing code like:

    var counter = 0;
    var f1 = Int32Array.from(f, e => e + counter++)

rather than

    var f1 = Int32Array.from(f, (e, i) => e + i)

However, this would not work in a parallel setting, since `counter`
would be shared mutable state. Parallel APIs require the second
approach. I would argue the second approach is preferable anyhow, as
it is a more declarative style.

I realize that the spec includes this comment about reusability:

"NOTE The from function is an intentionally generic factory method; it
does not require that its this value be the Array
constructor. Therefore it can be transferred to or inherited by any
other constructors that may be called with a single numeric argument."

There is no particular reason, though, that `from()` cannot include an
index and collection argument, even if the source value is not an
array. In that event, `index` simply represents the number of items
that have been iterated over thus far.