Support sampling in the range

[Jack Works]

originally proposed by @hax in #25

Iterator.range(10n, 20n, {count: 3n}) // 10n, 14n, 18n

it will sample 3 numbers in the range of 10n to 20n. without sampling, it would become

Iterator.range(start, end, {step: (end - start - 1n) / (count  - 1n)})

[Jordan Harband]

This seems like a good follow-on proposal, and a good argument for making it an options bag, but seems a bit beyond the scope of the initial proposal?

[Jack Works]

since the basic API shape is decided, adding useful options isn't out of the scope, but we can also leave it for the future.

[Jordan Harband]

True, but what are the problems being solved by sampling? I don't see any that were provided through the stage 1 or 2 advancements. New problems to solve suggests to me that a new proposal is appropriate.

[Michael Ficarra]

@Jack-Works I would disagree. The committee didn't approve an API space where you can throw in any features you want. The committee approved a specific solution to specific problems. Any increase in scope should be brought back to committee, even if it would have a minor change in the API.

[ogbotemi-2000]

@Jack-Works why don't you use an object parameter as follows:
Iterator.range = function(obj) { /* obj.start, obj.end, obj.step, obj['<someOtherPropertyConsideredLater>'] */ }

This approach allows for arbitrary placement of the arguments passed to Iterator.range as well as backwards-compatible implementations in the form of new parameters

[Jordan Harband]

Typically, options objects are used for optional parameters, not required ones.

[Jack Works]

@Jack-Works why don't you use an object parameter as follows:
Iterator.range = function(obj) { /* obj.start, obj.end, obj.step, obj['<someOtherPropertyConsideredLater>'] */ }

This approach allows for arbitrary placement of the arguments passed to Iterator.range as well as backwards-compatible implementations in the form of new parameters

I want to optimize for the most common use cases, which definitely have a start and end parameter.

It's also possible to do the thing you suggested when arguments length is 1, but I don't find a use case for now. (We can add it in the future if there is one).

[ogbotemi-2000]

Perhaps you did not understand my comment @Jack-Works
Here is what I meant

Iterator.range = function(obj) {
  /* obj.start, obj.end, obj.step, obj['<someOtherPropertyConsideredLater>'] */
  if(obj.start&&ob.end)  {
    //will be false for ob.start or obj.end = 0, implement correctly, just a suggestion
  }

}

Pros

• This approach will make the arbitrary and flexible placement of arguments passed to Iterator.range possible.

• A change in the spec down the line will involve breaking changes that may be solved by this approach.

• You need not even rely on overloading the function or on arguments.length === 1

Cons

• You will have to enforce that the first argument passed to Iterator.range is an object and not a number

[Tab Atkins Jr.]

No, they understood it. Jack and Jordan both explained why that's not an API shape we're going for - we don't usually put required arguments (like the start or end) into option bags, and specifying both start and end is very common. If you do want to just iterate from 0 to some limit, saying so is extremely simple, so we judged it's not worth the cost of adding a signature overload specifically for that case.

[HE Shi-Jun]

we don't usually put required arguments (like the start or end) into option bags

I agree.

@ogbotemi-2000 {start, end} looks more like a "range-like" object, if we chose reusable iterable api, we might explore such API shape (NumberRange.from({start, end})), but it's not very fit current proposal.

[Jack Works]

I'll close this issue for now for housekeeping. At today's TC39 meeting, delegates are generally satisfied with the status quo API. It's still possible to add this feature but we need to find the new motivation for this.