RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove (original) (raw)

Martin Buchholz martinrb at google.com
Mon Nov 21 20:32:29 UTC 2016

Previous message: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove
Next message: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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?

Previous message: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove
Next message: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the core-libs-dev mailing list