Paul Sandoz paul.sandoz at oracle.com
Thu May 2 12:41:23 PDT 2013


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



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.

More information about the lambda-libs-spec-observers mailing list