Cancelable streams

[Brian Goetz]

That's a different feature, and one that is more complex to spec (and 
this complexity is what almost pushed us to just give up on cancelation.)

The complexity comes from the parallel case, in the interaction with 
encounter order.  Users might do

   forEachUntil(e -> e.equals("3"))

on a stream of 1, 2, 3, 4, 5, 6

and be very surprised that on completion, elements 1, 3, and 6 have been 
processed.  They'll wonder "what happened to 2, it was before 3", and 
similarly wonder "why 6, it is after 3."



On 1/9/2013 2:56 PM, Remi Forax wrote:
> On 01/09/2013 08:44 PM, Brian Goetz wrote:
>> I've pushed a stream op "forEachUntil(Block, BooleanSupplier)".  After
>> offline discussion with Doug, this seemed to be an acceptable
>> alternative to having no cancelation support at all.
>>
>
> Sorry, I've forgotten to answer.
> While I agree with the concept, I think forEachUntil has the wrong
> signature, the issue I see is that some time you want to stop depending
> on a value which is a property of an element, but here the
> BooleanSupplier doesn't have access to the current element.
>
> I would prefer
>      void forEachUntil(Predicate<? super T> condition)
>
> so one can write
>      stream.forEachUntil(e -> e.accuracy <= 0.5)
>
> cheers,
> Rémi
>