Non interference enforcement

[Brian Goetz]

So far, that's right.  We're not currently proposing to add forEach to 
Iterator, though I wouldn't rule that out either.

ListIterator.remove(), though, removes the current element.  If we did:

interface ListIterator {
     default void forEach(Block<T>) {
         for (T t : this)
             block.accpet(t);
     }
}

Then
   listIterator.forEach(e -> { listIterator.remove(); });

would work but mostly by accident.  (If the subclass overrode forEach 
to, say, do lookahead, then it would not.)

On 9/26/2012 9:55 AM, Joe Bowbeer wrote:
> I'm asking whether ListIterator can be looped on, and if it can whether
> its remove method will work inside a loop.
>
> My take-away from your response is that ListIterator should *not* have a
> forEach method?
>
> On Wed, Sep 26, 2012 at 6:52 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     ListIterator does not currently have a forEach method (nor does
>     Iterator, for that matter.)  And its remove method is nilary.  So I
>     guess I do not follow your question?
>
>     On 9/26/2012 9:45 AM, Joe Bowbeer wrote:
>
>         Btw, at first glance, this code snippet looked like ListIterator
>         code
>         that would be allowed.
>
>         What about the following?  Is it legal?
>
>         listIterator.forEach(e -> { listIterator.remove(e); });
>
>
>         On Wed, Sep 26, 2012 at 6:26 AM, Remi Forax <forax at univ-mlv.fr
>         <mailto:forax at univ-mlv.fr>
>         <mailto:forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>> wrote:
>
>              We currently ask users to write lambdas that doesn't
>         interfere with
>              the source collection
>              of a stream but it's not enforced in the code.
>
>              By example,
>                 list.stream().forEach(e -> { list.remove(e); });
>              may works or not depending how the pipeline is implemented.
>
>              This is a serous departure for the current way java.util
>         collections
>              works
>              and I wonder if we should not keep the fail-fast guarantee
>         for those
>              collections.
>
>              Rémi
>
>
>