early exit when state becomes not-a-number

[michaelficarra]

The current spec text has a state (not-a-number) which can be entered but cannot be left. Why not early exit when we would enter this state? I don't see a good reason to consume the whole iterator. I don't care to have it throw if my iterator would have produced a non-Number if that's what you were going for.

[bakkot]

For consistency with every other method on Math, mostly. It seems weird to stop halfway.

[bakkot]

I also don't like that Math.sumExact(["foo", NaN]) would throw whereas Math.sumExact([NaN, "foo"]) wouldn't.

[michaelficarra]

Yeah I don't weigh those as highly as getting a quick exit when the first Number in my billion-Number-yielding iterator is NaN.

[bakkot]

Why are there any NaNs in your billion-Number-yielding iterator? That doesn't seem like a case we should be optimizing for.

[michaelficarra]

For any reason that NaNs show up generally. Could be from certain arithmetic operations. Could be from parsing unconstrained inputs. There's lots of reasons.

[bakkot]

In plenary some were in favor and some were against this change, but the balance of opinion was against.

[michaelficarra]

Assuming we get Iterator.prototype.takeWhile, I guess you can just stick a .takeWhile(n => !Number.isNaN(n)) onto your iterator. Unfortunately, that also puts the responsibility of pulling an iterable iterator out of the iterator on the consumer.