more support for bigint / refactor

[Fil]

I'm not sure this is the right way to do it, but I can't find another way… (we certainly don't want to create a normal array, peek at the values, then convert to typed array).

closes #1297

[mbostock]

I think what we do instead is split the current map function into map and typedMap, where map always returns an Array, and typedMap always returns a given TypedArray. Then, in the typedMap case we compose the given accessor with Number to safely coerce rather than relying on the implicit version which errors. (We could also short-circuit the additional number coercion if the input array is already a TypedArray.)

[Fil]

0d2e2d3 keeps a single entry point (map). Is it enough?

[mbostock]

a single entry point

My thinking was we can easily look for all places that are passing a TypedArray to map and change those to typedMap. That way we don’t need the type === Array test (which also isn’t strictly accurate, since you can technically subclass Array or TypedArray, so we’d have to use isTypedArray instead).

[Fil]

See #1305 for an exploration of typedMap vs. map.

[Fil]

I'll add more unit tests tomorrow and merge.

[mbostock]

I added some more tests. 👍 Feel free to add more. I feel confident in this change.

I spent some time thinking we could bypass the coerceNumber call for the integer array types (e.g., Uint8Array) since these types have no way of representing NaN, and hence you can’t avoid mapping null to 0. But I was forgetting that the other reason we want coerceNumber is to avoid the error coercing a BigInt to a number, which was the title of this PR, so I threw the work away. 😅