tc39 / proposal-iterator.range

A proposal for ECMAScript to add a built-in Iterator.range()
https://tc39.es/proposal-iterator.range/
MIT License
487 stars 13 forks source link

Rename to Iterator.ofNumbers? #58

Closed Jack-Works closed 1 year ago

Jack-Works commented 2 years ago

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).

ljharb commented 2 years ago

What current problem would that solve?

Jack-Works commented 2 years ago

What current problem would that solve?

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

ljharb commented 2 years ago

"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.

hax commented 1 year ago

@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 .

hax commented 1 year ago

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

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

Andrew-Cottrell commented 1 year ago
  • 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.

zloirock commented 1 year ago

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.