Number.range(from) for infinite range
bergus opened this issue · comments
I would suggest using undefined in the second parameter (to) to signal an infinite range. This would elegantly solve the BigInt problem #8, and seems more consistent to me than the overload that makes range(n) equivalent to range(0, n).
The resulting Range 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 simple for (x = a; x < b; x++) but rather to something like for (x = a; !(x >= b); x++). (I would however prefer to simply offer second desugaring in explanations, namely that for (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, where Number.rangeTo(n) ≡ Number.range(0, n).
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!