Actually, it's easier, then that, because you can construct and return delegates.
On Wed, Oct 12, 2011 at 12:13 PM, mta`chrono <[email protected]> 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. > >
