Rename to Iterator.ofNumbers?

[Jack Works]

Iterator helpers try to advance to stage 3 next meeting. If we rename this proposal to Iterator.ofNumbers, we can solve our current problem.

Not Iterator.range because I think there might be something like Iterator.ofChars in the future.

If we can rename it to Iterator.ofNumbers, I'll try to move this proposal forward with the current semantics (maybe with some simplification).

[Jordan Harband]

What current problem would that solve?

[Jack Works]

What current problem would that solve?

The name does not hint it is an iterator that can only be used once?

[Jordan Harband]

"it's an iterator" and "generators" should already hint that. Is that the primary source of objection from those who want something reusable, the name? I was under the impression that they wanted reusability, not that there was naming confusion.

[HE Shi-Jun]

@ljharb Even many people (include me) prefer reusable "range" due to various reasons, I don't think there is a very strong objection to a iterator/generator version if the API name is clear and don't cause confusion and misuse. I already suggest this direction in #57 .

[HE Shi-Jun]

I support renaming, but I also suggest we could consider only support integers, so the name will be Iterator.ofIntegers, because:

• the main use cases is iterating integers
• accumulate floating points always have precision problem which surprise the devs
• supporting floating points require a slightly complex algorithms

Even if we still want to support floating points, ofNumbers seems not fit because Number should not include bigints.

[Andrew-Cottrell]

• accumulate floating points always have precision problem which surprise the devs

The spec avoids accumulated floating-point error by using the following

18.j.i. Let currentYieldingValue be start + (step * currentCount).

where currentCount is a non-negative integer.

• supporting floating points require a slightly complex algorithms

I suggest any additional slight complexity is worthwhile as there are use cases (e.g., plotting charts & graphs, examining mathematical functions, producing test data) where it might be expected that a floating-point range function would a natural tool to use. We can use bijective transformations to & from integer coordinates (and might do so when plotting to a raster graphic), but these transformations increase conceptual complexity if they would not otherwise be necessary (to the extent that one might locally implement a floating-point range function instead of directly using Iterator.ofIntegers).

Even if we still want to support floating points, ofNumbers seems not fit because Number should not include bigints.

Agreed.

[Denis Pushkarev]

It's logical to have iteration methods on iterated types, otherwise, we will have Iterator.ofStrings, Iterator.ofDates, and tenths other methods that don't belong here - it's like move Array or Set iterators to this namespace. It's better to revisit #59.