One of the things I've said recently I find distasteful about foreach (not even foreach_reverse, just plain foreach) is that in the statement foreach(i; &obj.foreach){}  'foreach' doesn't really 'foreach' anything.  The method obj.foreach is the one that really contains the "for each" loop, and obj.foreach is the one that really decides if it will even be "for each item" or only "for some items".

In short 'foreach' only means 'foreach' if you use it in a particular way.

It occurred to me, though, that a similar argument applies to good old 'for'.

  for(i=0; i<3; i++) {}

C's 'for' is really totally cryptic if you think about it.  And can do just about anything you want it to, including things having nothing to do with 'for'-ing.
  for(do_laundry();  wash_car() ; clean_room()) {
     take_out_the_trash();
  }
That's legal, but whatever it's doing sure is not 'for'-ing anything.

I kind of stopped seeing that years ago though.  Thinking back, however, I can remember the very early days staring at the first few 'for' statements I ever saw in K&R, trying to figure out what the heck all those semicolons were doing, and why good old "for i=1 to 10" wasn't good enough, and later flipping back and forth in K&R to figure out for-loop code later in the book.

foreach is pretty similar.  It may have many uses that have nothing to do with 'foreach'-ing, and the meaning of the semicolon is meaningless and unclear at first, but I'll probably get used to it.

That doesn't mean it's an optimal design, though. ;-P

Nor does it mean that I wouldn't like trailing delegates to work also:
    obj.each() (int i) {
      writefln(i);
    }

Maybe I can get used to this version that works now:
    obj.each( (int i) {
      wrietfln(i);
    })

But it just looks weird to have my loop body inside the parens, and will look even weirder if nested
    obj.each( (Obj c) {
      c.each( (int i) {
        writefln(i);
      })
    })

It sort of looks like nested loops, but I just can't get excited about all those })'s screaming out "I'm a not a loop! I'm a function call!".

All that's just about plain 'foreach'.  I still can't see a good justification for foreach_reverse.  Reverse iteration just isn't common enough to justify a special case like that.

--bb

> All that's just about plain 'foreach'.  I still can't see a good justification for foreach_reverse.  Reverse iteration just isn't common enough to justify a special case like that.

I finally think Walter is right with foreach_reverse. It will be used mostly with arrays, and the compiler can then optimize the loop.

Read this: http://www.digitalmars.com/d/faq.html#foreach

Replace the article with:

---
When should I use a foreach_reverse loop rather than a for?

By using foreach_reverse, you are letting the compiler decide on the optimization rather than worrying about it yourself. Is it just performance or readability?
---

:)

Maybe the compiler can't optimize that much. But D is a system's programming language, and then it should do as much effort as possible to optimize the final code.

Ary

Ary Manzana wrote:
>> All that's just about plain 'foreach'.  I still can't see a good justification for foreach_reverse.  Reverse iteration just isn't common enough to justify a special case like that.
> 
> 
> I finally think Walter is right with foreach_reverse. It will be used mostly with arrays, and the compiler can then optimize the loop.
> 
> Read this: http://www.digitalmars.com/d/faq.html#foreach
> 
> Replace the article with:
> 
> ---
> When should I use a foreach_reverse loop rather than a for?
> 
> By using foreach_reverse, you are letting the compiler decide on the optimization rather than worrying about it yourself. Is it just performance or readability?
> ---
> 
> :)
> 
> Maybe the compiler can't optimize that much. But D is a system's programming language, and then it should do as much effort as possible to optimize the final code.

Hmm.  From that page:
>> Like register assignment, let the compiler do the optimization.

That's great, but adding foreach_reverse is basically a 'register'-like hint to the compiler that isn't smart enough to figure out how to optimize this:
  foreach(i; &foo.reverse)

That's fine, though, the 'register' keyword was also useful as a way to micro-optimize C code in the old days.  Just kinda goes against the D philosophy of the "trust the compiler; the compiler is smarter than you".

--bb

Bill Baxter wrote:

> Maybe I can get used to this version that works now:
>     obj.each( (int i) {
>       wrietfln(i);
>     })
> 
> But it just looks weird to have my loop body inside the parens, and will look even weirder if nested
>     obj.each( (Obj c) {
>       c.each( (int i) {
>         writefln(i);
>       })
>     })
> 
> It sort of looks like nested loops, but I just can't get excited about all those })'s screaming out "I'm a not a loop! I'm a function call!".

I'm not to happy about foreach_reverse (more neutral than anything) but I do see a major advantage of both foreaches over the form mentioned above:

outer: foreach(Obj c; &obj.each)
   foreach(int i; &c.each)
   {
      break outer;
      continue outer;
      break;
      continue;
      return;
   }

any of the lines in the inner loop quickly become an ugly hack when the user is writing the blocks as delegates.

> 
> All that's just about plain 'foreach'.  I still can't see a good justification for foreach_reverse.  Reverse iteration just isn't common enough to justify a special case like that.
> 

A templateized reverse iterator would be good enough for me.

int delegate(int delegate(T)) reverse(T)(T[]){...}

foreach(int i; reverse([1,2,3,4,5,6,7,8,9]))
{
}

> --bb

BCS wrote:
> Bill Baxter wrote:
> 
> I'm not to happy about foreach_reverse (more neutral than anything) but I do see a major advantage of both foreaches over the form mentioned above:
> 
> outer: foreach(Obj c; &obj.each)
>    foreach(int i; &c.each)
>    {
>       break outer;
>       continue outer;
>       break;
>       continue;
>       return;
>    }

True.  But I think I've needed to break out of inner loops like that maybe 5 times in 20 years of coding.  YMMV.

> any of the lines in the inner loop quickly become an ugly hack when the user is writing the blocks as delegates.

--bb

Bill Baxter wrote:
> 
> 
> True.  But I think I've needed to break out of inner loops like that maybe 5 times in 20 years of coding.  YMMV.
> 
> 

It has varied quite a bit actually, but maybe that says something (good, bad or otherwise) about my codeing style.

> 
> --bb

Bill Baxter wrote:
> Maybe I can get used to this version that works now:
>     obj.each( (int i) {
>       wrietfln(i);
>     })
> 
> But it just looks weird to have my loop body inside the parens, and will look even weirder if nested
>     obj.each( (Obj c) {
>       c.each( (int i) {
>         writefln(i);
>       })
>     })

I don't understand your point. You can already write something like:

obj.each = (int i) {
    writefln(i);
};

Julio César Carrascal Urquijo wrote:
> Bill Baxter wrote:
>> Maybe I can get used to this version that works now:
>>     obj.each( (int i) {
>>       wrietfln(i);
>>     })
>>
>> But it just looks weird to have my loop body inside the parens, and will look even weirder if nested
>>     obj.each( (Obj c) {
>>       c.each( (int i) {
>>         writefln(i);
>>       })
>>     })
> 
> I don't understand your point. You can already write something like:
> 
> obj.each = (int i) {
>     writefln(i);
> };


Yup, or

obj.each in (int i) {
    writefln(i);
};

But it will only look like a loop of some sort. Neither continue, break nor return will work in its body.
The trailing delegate extension would make life easier *hint* *hint* ;)

Tom S wrote:
 > Yup, or
> 
> obj.each in (int i) {
>     writefln(i);
> };

Well yes, "in" looks better but it doesn't work right now, "=" does.

> But it will only look like a loop of some sort. Neither continue, break nor return will work in its body.
> The trailing delegate extension would make life easier *hint* *hint* ;)

I see, that would certainly require compiler support, like what the compiler is doing for the foreach statement (Returning an int to flag break, continue, return) or it will be forcing the user to write the return statements all the time.

Julio César Carrascal Urquijo wrote:
> Bill Baxter wrote:
> 
>> Maybe I can get used to this version that works now:
>>     obj.each( (int i) {
>>       wrietfln(i);
>>     })
>>
>> But it just looks weird to have my loop body inside the parens, and will look even weirder if nested
>>     obj.each( (Obj c) {
>>       c.each( (int i) {
>>         writefln(i);
>>       })
>>     })
> 
> 
> I don't understand your point. You can already write something like:
> 
> obj.each = (int i) {
>     writefln(i);
> };
> 

How do you set that up?  Something like this?

class ObjClass
{
   class EachClass {
      void opAssign( void delegate(...) ) {
           [...]
      }
   }
   EachClass each = new EachClass();
}
ObjClass obj = new ObjClass();

Or is there a better way?

--bb