Yet another strike against the current AA implementation

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-04-26 11:46:51 -0400, dsimcha <dsimcha at yahoo.com> said:
> 
>> == Quote from Michel Fortin (michel.fortin at michelf.com)'s article
>>> Hum, are you saying opApply superior when it comes to iterating in a
>>> tree? It seems that with opApply you could use the stack by recursively
>>> calling opApply with the given delegate on each one of the branches.
>>
>> Exactly.  On the other hand, you lose a lot of flexibility with 
>> opApply.  If you
>> tried to port most of std.range to operate on the opApply interface 
>> instead fo the
>> forward range interface, I doubt you'd get very far.
>>
>> IMHO, though, opApply should *not* be deprecated.  opApply and ranges 
>> attempt to
>> solve similar problems, but not the same problem.  Ranges attempt to 
>> solve the
>> problem of iterating over some object with maximum flexibility from 
>> the point of
>> view of the user of the object.  opApply attempts to solve the problem of
>> iterating with maximum flexibility from the point of view of the 
>> implementer of
>> the object.  In some cases, like the one you just described, the 
>> latter can be
>> better.
> 
> Indeed. I certainly agree that both ranges and opApply have their place.
> 
> So what the implementer can do with opApply is write an optimized 
> iteration algorithm for use with foreach. Which may mean that when both 
> opApply and ranges are available for generating foreach's code, the 
> compiler should favor opApply. Currently, I believe it's the reverse.

I think, all other things being equal, that opApply tends to be slower 
than iterators.

Andrei