No-reuse streams

[Zhong Yu]

What about a Stream *is a* Iterator? Or just ditch Iterator, add
hasNext()/next() methods in Stream interface?

On Mon, Nov 19, 2012 at 10:19 AM, Aleksey Shipilev
<aleksey.shipilev at oracle.com> wrote:
> 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.
>>>
>
>