retrying: 10 things you must know about ListBuffer

I'd say let it loop. The behavior of iterating over collections that are concurrently modified is unspecified. Anything can happen. I'd even say let it loop in the Traversable case. It's a runtime check which costs time and only catches one special case (what if the traversable you are accessing is a Proxy of the one that gets appended? You'd be hosed in any case).

Cheers

 -- Martin

On Tue, Mar 23, 2010 at 8:24 PM, Paul Phillips <paulp@improving.org> wrote:

Even with all the recent Iterator conversation, not a single opinion on
this, for or against? I want to fix it one way or another so I might be
inclined to interpret total silence as "brilliant idea paulp!" but for
the fact that this could be a pretty far-reaching change.  Though I do
think it's the right thing.

At least the crickets are my friends.

To me, it makes sense to let it loop too. How the behavior be specified in a way that avoids looping and preserves evaluation on demand? If a clear specification can be provided, I'd be happy to consider it, but it doesn't look like this is the case. I'd rather just note the loop condition in the scaladoc, and recommend people to just create a new iterator if they want to do something like this.

On Tue, Mar 23, 2010 at 4:24 PM, Paul Phillips <paulp@improving.org> wrote:

Even with all the recent Iterator conversation, not a single opinion on
this, for or against? I want to fix it one way or another so I might be
inclined to interpret total silence as "brilliant idea paulp!" but for
the fact that this could be a pretty far-reaching change.  Though I do
think it's the right thing.

At least the crickets are my friends.

On Tue, Mar 23, 2010 at 10:09:19PM +0100, martin odersky wrote:
> I'd say let it loop. The behavior of iterating over collections that
> are concurrently modified is unspecified. Anything can happen. I'd
> even say let it loop in the Traversable case. It's a runtime check
> which costs time and only catches one special case (what if the
> traversable you are accessing is a Proxy of the one that gets
> appended? You'd be hosed in any case).

You're right, the check that's in there is easily fooled, but counting
isn't. The way I see it we have a lurking infinite loop which we know
about, and which we can fix at what I would call negligible cost (though
I'll retract that if the facts on the ground say otherwise.) Nobody is
going to confuse me with a bleeding-heart "make life easy for the
mutables" sort of guy, but as long as they're in the library I don't
think they need to be decked out in poison spikes which shoot streams of
hornets at you.

Just seems cruel to knowingly allow this to enter an infinite loop. As
I'm sure you know when these things strike it doesn't tend to be by way
of toy example, but unanticipated aliasing.

def f[T](x1: Traversable[T] with Growable[T], x2: Traversable[T]) = {
assert(x1.size == 1)
assert(x2.size == 1)
assert(x1 ne x2)

x1 ++= x2
}

// that looks like it terminates? THINK AGAIN, SUCKERS!
val b = ListBuffer(1)
println(f(b, b.view))

This all can and should wait, regardless.