No-reuse streams

[Aleksey Shipilev]

Well, of course!

I was thinking about returning the same iterator nevertheless; so that
we share the traversal states between two iterators from iterator()
call. I think this provisioning would help to write cleaner code in some
of the cases, at the cost of making stream appear to bear the state. I'm
fine with opting out of that behavior if it is considered not that clean.

-Aleksey.

On 11/19/2012 07:50 PM, Brian Goetz wrote:
> The iterator() method (and soon, spliterator()) are the escape hatch for
> "the library can't help me, I have to do it myself."  You then get the
> iterator and can do whatever you want with it.  But, what you can't do
> is call iterator(), pull elements from the stream, and *then* try and do
> more stream operations on that stream.
> 
> On 11/19/2012 10:01 AM, Aleksey Shipilev wrote:
>> On 11/19/2012 06:29 PM, Paul Sandoz wrote:
>>> Brian and I just pushed a changeset that:
>>>
>>> - turns Stream/IntStream.iterator() into a terminal operation
>>>
>>> - only one terminal operation may be performed on at most one stream
>>> in the pipeline, otherwise an ISE will be thrown.
>>
>> Isn't iterator() the exception from this rule, being the "extension" of
>> the stream? I would naturally presume the *same* iterator is returned
>> for the given stream, so this will still be the valid code:
>>
>>   Stream<T> stream = ...;
>>   T first = stream.iterator().next()
>>   // ...many, many lines of code...
>>   T second = stream.iterator().next()
>>
>> -Aleksey.
>>