PROPOSAL: Enhanced for each loop iteration control

Derek Foster vapor1 at
Wed May 6 01:46:01 PDT 2009

-----Original Message-----
>From: Stephen Colebourne <scolebourne at>
>Sent: May 1, 2009 4:16 AM
>To: coin-dev at
>Subject: Re: PROPOSAL: Enhanced for each loop iteration control
>2009/5/1 Derek Foster <vapor1 at>:
>> Firstly, I have very rarely needed to call Iterator.delete() in a loop. (I can think of maybe four or five occasions.) As such, it has usually not been a great deal of trouble to just write the loop using an explicit iterator.
>Thanks for the numeric feedback. It may depend on coding style. 5% of
>the loops in the enterprise system I work on have remove().

It probably does depend on coding style to some degree. In my coding, I very much tend to prefer immutable data structures and "functional-like" algorithms with no external side-effects when possible. Thus, I would usually rather copy a list, creating a new list that is a filtered version of the original, than to modify the original list by removing the elements that I don't want.

>> I would much prefer to have a simpler syntax that allowed me to work just with an index or just with an iterator... Actually, I'd be happy if just indices were supported. Something like:
>> Thing[] fooCollection = ...whatever...;
>> String[] results = new String[fooCollection.length];
>> for (Thing foo : fooCollection) {
>>     results[#foo] = foo.toString();
>> }
>> where "#foo" was defined by the compiler as "the index of foo within the collection it is iterating over".
>#foo has a meaning in FCM as a field reference, and similar syntax was
>adopted by BGGA (unpublished as a document).

I was just using the leading # as an example. Other syntaxes ("indexof(foo)", "foo..index", "##foo", "$@@!#$@foo" or whatever else comes to mind could be candidates. Basically, all we need is a unary operator, unary function, or other way to indicate that in certain references, we want the index associated with the loop variable and not the variable itself.)

>It should also be noted that this approach breaks on nested loops (its brittle).

I don't understand what you mean by "breaking on nested loops". Support for nested loops is why I suggested "#foo" instead of just "#"... the specification use of the loop variable indicates the nesting level. For instance, you could do something like:

for (Thing foo : whatever) {
    for (Thing bar : whateverElse) {
         doSomethingWith(foo, bar, #foo, #bar);


More information about the coin-dev mailing list