Can we get rid of opApply?

[Steven Schveighoffer]

"Fawzi Mohamed" wrote
>I think that opApply should stay
>
> 1) range (iterators, whatever) hide the iteration step, this allows to 
> iterate several of them in lockstep (nice)
>
> 2) opApply hides the iteration loop this allows one to make parallel loops 
> (nice)
>
> I have successfully used opApply as follow
>
> auto a=zeros([100,100]);
> foreach (ref i;a.pLoop){
>  i+=4+i;
> }
>
> This can be dangerous (the loop content cannot have non synchronized 
> sequential dependencies), but I find it quite nice...
>
> So I think that both solutions have their place.

Probably the best argument for opApply that I've seen.

The other possibly sensible reason to keep opApply is for 
interfaces/classes.  Ranges as a class would be slower than even opApply, as 
each loop iteration would call a virtual function.  However, how do you 
define an interface that says "you must define a range with these 
parameters"?

opApply makes that easy:

interface I
{
  int opApply(int delegate(ref int x));
}

With a range, you'd have some weird stuff, like a predefined range struct 
which calls virtual functions on the interface, or a range class instead of 
a struct (Yuck!)

So maybe the answer is that we keep opApply for parallelization and 
polymorphism, but use ranges for structs and compile-time parameterization.

At the very least, we can get rid of the term opApply, and just use opCall 
instead (see bugzilla issue 2498 for my thoughts on that).

-Steve