RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

[Paul Sandoz]

> On 21 Nov 2016, at 12:32, Martin Buchholz <martinrb at google.com> wrote:
> 
> Thanks.  Seems like progress.
> 
> The spec below seems like it could be improved, but not sure how...
> 
> +     * <p>
> +     * The behavior of an iterator is unspecified if the action performs the
> +     * following side-effects:
> +     * <ul>
> +     * <li>modifies the underlying collection; or
> +     * <li>calls the {@link #remove remove} method.
> +     * </ul>
> +     * <p>
> +     * Subsequent behavior of an iterator is unspecified if the action throws an
> +     * exception.
> 
> 
> Maybe """The behavior of an iterator is unspecified if an action modifies the collection in any way (even by calling the {@link #remove remove} method).”””

I am ok with that.


> There's the question of what to promise after a call to forEachRemaining (whether or not an action threw).  Perhaps a blanket
> """Subsequent behavior of an iterator is unspecified after a call to this method."""
> 

I think that is overly limiting, it’s exceptions and remove that are problematic. Assuming no exception it is fine to subsequently call next, hasNext and forEachRemaining, each has well defined behaviour (throws NoSuchElementException, false, no-op respectively).


> The default implementation cannot ensure desirable properties we might easily implement for a concrete implementation, e.g. whether the iterator is exhausted after a call to forEachRemaining where an action threw.
> 

It does tie our hands somewhat.


> Should we be aligning Iterator and Spliterator, which have similar questions?

Thankfully Spliterator has no remove and no default methods :-)  so we are in an easier position, but yes we could align regarding exceptions thrown by actions.

Paul.