RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove
Martin Buchholz
martinrb at google.com
Mon Nov 21 20:32:29 UTC 2016
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)."""
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."""
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.
Should we be aligning Iterator and Spliterator, which have similar
questions?
More information about the core-libs-dev
mailing list