Closed bergus closed 4 years ago
That would also mean that omitting the second argument would implicitly be Infinity. That seems problematic.
Why do you consider that to be a problem? I think it's a feature. Number.range(a, b)
corresponds to the range [a .. b-1]
, and Number.range(a)
corresponds to the range [a .. ]
. I consider it confusing to have it swap sides if the second argument is omitted.
The range(to)
semantics is inspired by Python style (https://docs.python.org/3.5/library/functions.html#func-range).
But if there are different thoughts on the overload, maybe it's better to not allow any kind of overload.
I would prefer explicitness. There is no much benefit to save several keystrokes.
It seems like there's less support for (from)
compared to (to)
. So I decided to close this issue, but this doesn't mean I'll choose the (to)
overload.
I will stay on the current design until I consider it more clearly (or it's become a consensus that we should add (to)
overload).
maybe it's better to not allow any kind of overload.
Thanks for your suggestion!
I would suggest using
undefined
in the second parameter (to
) to signal an infinite range. This would elegantly solve theBigInt
problem #8, and seems more consistent to me than the overload that makesrange(n)
equivalent torange(0, n)
. The resultingRange
instance would basically "not have an.end
", i.e.Number.range(n).end === undefined
.The only downside would be that
for (x of Number.range(a, b))
would no longer desugar to the simplefor (x = a; x < b; x++)
but rather to something likefor (x = a; !(x >= b); x++)
. (I would however prefer to simply offer second desugaring in explanations, namely thatfor (x of Number.range(a, undefined))
≡for (x = a; true; x++)
.)If there is a large want for the isAcceptAlias feature, I would propose having a separate
rangeTo
method, whereNumber.rangeTo(n)
≡Number.range(0, n)
.