foreach(r; requests) { r.concider(); }
Gor Gyolchanyan
gor.f.gyolchanyan at gmail.com
Wed Oct 12 01:24:21 PDT 2011
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.
>
>
More information about the Digitalmars-d
mailing list