-
Notifications
You must be signed in to change notification settings - Fork 34
Throw RangeError
on bad numeric arguments to take/drop?
#169
Comments
Most places in the spec don't guard - I think there's a pretty good case to be made for checking for I'd be in favor of throwing when the argument coerces to |
NaN as direct input, probably, but not as undefined. Pretty much everything that accepts an offset, index, or length allows omission/undefined because of ToIntegerOrInfinity: undefined -> NaN -> 0. So it's not just that |
Passing |
Currently, this proposal coerces arguments passed to
drop
andtake
to integers without range checks other than for negative numbers becauseToIntegerOrInfinity
is used to coerce the argument passed in.This has the potential to create confusing behavior - for example
naturals().take(NaN)
andnaturals().take((x) => x < 15)
andnaturals().take('aaa')
all return an empty iterable.I think most other places the spec does this get away with it by checking an explicit range (e.g. toString on numbers requiring the radix being at least 2) but admittedly some places don't (e.g. toExponential happily accepting NaNs).
I think it would provide better developer experience to get
RangeError
s on NaNs (basicallyToNumber
the argument first and throw a RangeError on NaNs).The text was updated successfully, but these errors were encountered: