Ranges

[Paul Sandoz]

Hi,

Any thoughts below on the following? use-cases? experiences?

Paul.

--

At the moment we have the {Int, Long, Double}Stream.range methods for a half open range of a step of 1 or a configurable step >= 0.

Do we really require the configurable step methods? Perhaps they are not that common, if so should we remove them?

Certainly one can achieve a step > 1 using map(i -> i * n), albeit less efficiently. Note that this will not check for overflow when the upper bound declared to be the maximum value.

-- 

The fact that we only have a half open range confuses some. Developers i think tend to prefer:

  IntStream.rangeClosed('A', 'Z')

rather than:

  IntStream.range('A', 'Z' + 1)

So it seems useful to add {Int, Long}Stream.rangeClosed().

--

Do we require a method for descending ranges, for example {Int, Long}Stream.rangeDec? what about for closed descending ranges?

Again those can be achieved using map, albeit less efficiently and with overflow errors, and perhaps developers will make simple errors expressing the mapping?

--

For DoubleStream.range i think supporting +ve/-ve steps is useful e.g. [0, 2 * pi, pi / 180] and [2 * pi, 0, -pi / 180]

Should the range always be closed, half open or both? 

Half open ranges for Int/Long make sense because of the correlation with array indexes.

--

Should we support sizes for LongStream.range that are > Long.MAX_VALUE? for example:

  LongStream.range(Long.MIN_VALUE, Long.MAX_VALUE)

The top-level Spliterator of such a stream cannot report SIZED or SUBSIZED and would report an estimate of Long.MAX_VALUE.

DoubleStream.range is restricted to a maximum of Long.MAX_VALUE. This simplifies the implementation, since it is equivalent to:

  double size = Math.ceil((endExclusive - startInclusive) / step);   
  LongStream.range(0, (long) size).mapToDouble(i -> startInclusive + i * step);

and a simplified version of the long range spliterator is used.