Expected behavior of a Streams.cycled() instance - found issues and questions

[Peter Levart]

On 10/23/2012 07:11 PM, Brian Goetz wrote:
>> >1) Should it be allowed (as it is now) to concat to the end of an
>> >infinite (cycled for example) stream?
> It doesn't seem so useful, but also such attempts to protect the user
> from themselves are also often counterproductive, especially if "known
> infinite" really means "probably infinite."  For example, what about:
>
>     infiniteStream.filter(t -> false)
>
> So the answer is "maybe, but maybe not."
>

Hi,

"known infinite" vs. "probably infinite". "probably infinite" is more 
useful. But the name is not exact.

Maybe the INFINITELY_SIZED flag should be renamed to INFINITELY_TIMED. 
Meaning that evaluating the (whole) stream never completes. This implies 
that the size is not known.

Streams.repeat(stream) is INFINITELY_TIMED (unless 'stream' knows it's 
size and it is 0 in which case .repeat can optimize and return an empty 
stream).

infinitelyTimedStream.filter(t -> false) is still INFINITELY_TIMED (and 
the framework still can not know it's size)

sorting an INFINITELY_TIMED stream will always: either not complete or 
throw OOME, so instead of exercising memory pressure to stop the 
algorithm, framework could throw an exception (unless user actually 
wanted to program an infinite loop - what a freak). The same goes with 
groupBy. Uniq is different, at least the serial variant which is 
pass-through and is useful when downstream only consumes a limited 
number of elements, but the parallel Uniq will always: either not 
complete or throw OOME.

On a second thought, I think that infinite loops should not be prevented 
though. Someone might want to program termination logic by throwing an 
exception (what a freak :-). As there is no .filterWhile(Predicate) or 
such, this might be he's only choice...

Regards, Peter