Cancelable streams (original) (raw)

Brian Goetz brian.goetz at oracle.com
Wed Jan 9 12🔞32 PST 2013

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

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