foreach(r; requests) { r.concider(); }

[Steven Schveighoffer]

On Wed, 12 Oct 2011 03:55:36 -0400, Gor Gyolchanyan  
<gor.f.gyolchanyan at gmail.com> wrote:

> The foreach loop is truly a marvelous tool, which allows one to
> implement custom iterations, which look and feel just like all other
> kinds of iterations.
> The only philosophical problem with it is, that it thinks that only
> classes and structs can be looped over in a custom way and that they
> can have only one way to be iterated over.
> It would be great to be able to implement iterative algorithms for
> arbitrary types (templated iterations), like strided iteration to
> extract the red part of an image.
> It would also be great to be able to have more, then one kind of
> iteration for every type of iterable.

You can already do this.

struct Iterable
{
    int opApply(int delegate(ref int) dg)
    {
       int result = 0;
       foreach(int i; 0..100)
       {
          auto t = i; // I hate this part of opApply BTW.
          if((result = dg(t)) != 0) break;
       }
       return result;
    }

    int inReverse(int delegate(ref int) dg)
    {
       int result = 0;
       foreach(int i; 0..100)
       {
          auto t = 99-i;
          if((result = dg(t)) != 0) break;
       }
       return result;
    }
}

void main()
{
    Interable it;
    foreach(i; it) {}
    foreach(i; &it.inReverse) {}
}

I've proposed an enhancement to make this better:

http://d.puremagic.com/issues/show_bug.cgi?id=2498

> Here's the list of what I mean by that:
> 1. Allow passing parameters to iterables in foreach:
>     foreach(c, i; MyType(), 3) { }
>     the `3` would be passed to MyType's opApply right after the
> delegate (of such an overload of opApply is available, of course).

This might be useful, but I don't like the syntax.

My preference would be to pass the parameters to the function itself, and  
infer the delegate from the foreach body.  i.e.:

struct Iterable
{
    int foo(int x, int delegate(ref int) dg) {...}
}

Iterable it;
foreach(i; it.foo(3)) {...}

Of course, this syntax is predicated on acceptance of my afore-mentioned  
enhancement request.

> 2. Allow named foreach loops:
>     foreach strided(c, i, MyType, 3) { }
>     the `strided` is passed as a template parameter to the opApplly,
> which (depending on what overloads of opApply are available) may be
> optional.

I don't see a large benefit of this over already existing foreach(c, i;  
&MyType.strided)

> 3. Allow free-function opApply, which could be templated to work with
> any kind of iterable in a specific way:
>     int opApply(string name : "strided", Iterable)(Iterable iterable,
> int delegate(ForeachParamsTuple!Iterable) dg, size_t stride) { /* ...
> */ }
>     this function would allow you to add stride to any iterable. the
> `ForeachParamsTuple` will return the tuple of parameters of the given
> iterable type.

Again, enhancement 2498 could be used for this.

> 4. Allow foreach loops with a single iterator to be specified without
> a body, in which case it would return an input range (or some other
> type of range), lazily evaluating and returning the iterator.
>     void printRange(Range)(Range range) { foreach(r, range) {   
> writeln(r); } };
>     unittest { printRange(foreach(i; 0..100)); }

This is not a good idea, since translating from an opApply loop to a range  
is not possible without spawning a new thread or copying the data.

The reason is simple -- foreach loops using opApply execute in the context  
of the opApply function, they cannot leave that context, and the context  
requires full use of the program stack.

I don't see a huge benefit of doing this vs.:

foreach(i; 0..100) writeln(i);

-Steve