Thanks Allen. The

> ```js
> var squaredSmalls_try2= Int16Array.from(smalls.map(v=> v*v));   // still no good, because intermediate array is Int8Array
> ```

example certainly clears it up for me. Tricky stuff.

I was going to write "it's still a bit weird to me that we overload `Array.from` with the mapping functionality", but then I realized this is only weird because of my preconceptions about `Array.from` dating back from when we first discussed it on-list.

Taken on its own, without any historical bias, I think it's fine for `Array.from`, and more importantly `Int16Array.from` etc., to take a mapping function. You derive a new `Int16Array` "from" another iterable, optionally via some rule. Makes sense!

Thanks Allen. The

> ```js
> var squaredSmalls_try2= Int16Array.from(smalls.map(v=> v*v));   // still no good, because intermediate array is Int8Array
> ```

example certainly clears it up for me. Tricky stuff.

I was going to write "it's still a bit weird to me that we overload `Array.from` with the mapping functionality", but then I realized this is only weird because of my preconceptions about `Array.from` dating back from when we first discussed it on-list.

Taken on its own, without any historical bias, I think it's fine for `Array.from`, and more importantly `Int16Array.from` etc., to take a mapping function. You derive a new `Int16Array` "from" another iterable, optionally via some rule. Makes sense!