Methods on Number.prototype instead

[ByteEater-pl]

How about Scala way? 3 .to(5) // 3, 4, 5 (3).to(5) // same, some may prefer stylistically 3..to(5) // same, some may prefer stylistically 3.1.to(5.1) // 3.1, 4.1, 5.1 // beware of rounding, paradoxes ahead! 3 .until(4.1) // 3, 4 3.1.until(5.1) // 3.1, 4.1 // beware of rounding, paradoxes ahead! 9 .to(6, -1) // 9, 8, 7, 6 9 .to(7, -2) // 9, 7 9 .until (7, -2) // 9 1 .to(1, 0) // infinite sequence of 1s 1 .until(1, 0) // nothing Infinity.to(Infinity) // Infinity Infinity.until(Infinity, 0) // nothing Infinity.to(7, -3) // infinite sequence containing only Infinity

Possibly also with detection of direction when second argument is something special (NaN, "s" (my preference), some symbol).

If the first argument is undefined, it should be treated as -Infinity if the second one is negative and Infinity otherwise. The latter's default value should be 1.

This doesn't specially address the common 0 case but "0 .to" seems short enough.

[Jack-Works]

I personally think we should careful about adding things on the prototype.

[tiansh]

1. I like something like number#to but I don't want to see 0 .to, 0..to, or (0).to any more. So I would prefer vote -1 here.
2. Adding methods on prototype is some how dangerous. But adding static methods to Number is dangerous too. A quick search on GitHub shows me that there are some codes which defined their own Number.range and some even include the last value.
3. I don't think there is anything wrong if 0.1.to(2.3, 0.2) does not include 2.3. (That's what expected for floating point operations. And nothing we can do here.)

[Jack-Works]

About the conflict. This problem is different from Array#flatten. They (Mootools) enumerate on the Array.prototype and flatten is not copied.

I don't think this will happen on Number.range. Is anyone write for (var x in Number)?

If anyone use their own Number.range, native one will be overwrited.

Reference: https://developers.google.com/web/updates/2018/03/smooshgate

[ljharb]

It could still cause a problem if someone’s Number.range conditionally overwrites, and has different semantics.

[Jack-Works]

https://github.com/lovelyscalabledrawings/lsd-script/blob/b2ef2fc14e006a4afb15d48e1e6958d798bd961b/Source/Helpers/Native.js#L31

Alright. Not on Number.prototype. I found someone enumerate on Number.prototype.

Update: Oh he didn't use range in his code.

[hax]

We could leave it to bind operator / extensions.

1::to(3) // Number.range(1, 3 + 1)
1::until(3) // Number.range(1, 3)