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

[Gor Gyolchanyan]

Well, yeah. This is a fairly good workaround, but it's a workaround nonetheless.
The existence of this workaround makes this request less prioritized, no doubt.
But it's still much cleaner and less prone to run-time overhead.


On Wed, Oct 12, 2011 at 12:13 PM, mta`chrono
<chrono at mta-international.net> wrote:
> I understand that you've suggested a different approach. But you can already
> implement some kind of custom iterations. Just create a function that
> returns this.
>
> class CustomDataClass
> {
>      public typeof(this) filter(Color col)
>      {
>             // ...
>             return this;
>      }
>
>      void opApply(....) ...
> }
>
>
> auto datas = CustomDataClass();
> foreach(u, i; datas.filter(Color.Red))
> {
>     // ...
> }
>
>
> ----------------
>
> Am 12.10.2011 09:55, schrieb Gor Gyolchanyan:
>>
>> 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.
>> 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).
>> 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.
>> 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.
>> 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 would vastly improve the usability and performance of
>> iterable types and ranges, since you no longer need to cache and copy
>> around the data and you don't need to wrap it around delegating
>> structs or classes either.
>>     The overloaded opApplies could be allowed to construct and return
>> those ranges themselves.
>> Yes, i know, you might have some questions like "but<this>  wouldn't
>> work with<that>." I thought it out pretty carefully and the details
>> are numerous, so I'd rather just answer those questions as they occur,
>> instead of listing them all here.
>>
>> Given these four improvements iterations would become very easy and
>> powerful.
>> The iterations would become very flexible and easily used with
>> range-based algorithms.
>
>