Can we get rid of opApply?

[Steven Schveighoffer]

"Denis Koroskin" wrote
> On Wed, 21 Jan 2009 01:38:50 +0300, Steven Schveighoffer 
> <schveiguy at yahoo.com> wrote:
>
>> "Daniel Keep" wrote
>>>
>>>
>>> Steven Schveighoffer wrote:
>>>> "Robert Fraser" wrote
>>>>> Steven Schveighoffer wrote:
>>>>>> 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.
>>>>> There would only need to be one vtable lookup for each function (since
>>>>> every iteration would use the same head(), next(), etc.) So it would 
>>>>> be
>>>>> the same price as opApply (a function pointer call). Well, 3 times the
>>>>> price, since 3 functions need to be called.
>>>>
>>>> You could technically cache the vtable lookup, but a vtable call costs
>>>> more
>>>> than a delegate call (one lookup for vtable, then function + pointer 
>>>> call
>>>> vs. just function + pointer call).  But besides that, yes, it would be 
>>>> 3
>>>> functions called per iteration.  So still slower...
>>>>
>>>> -Steve
>>>
>>> Add opRange and allow it to return a struct.
>>
>> How do you define that in an interface?  You must pre-define the struct,
>> which means the struct must have implementation details before the class 
>> is
>> even written.
>>
>> -Steve
>>
>>
>
> Interface implies virtual methods. As such, you can use the following:
>
> interface IRange(T)
> {
>    T head();
>    bool empty();
>    void next();
>
>    IRange!(T) opRange();
> }

Interfaces can only be implemented by classes.  So your IRange!(T) still is 
using virtual functions for the range methods.  The performance benefit from 
ranges comes from when the range is a struct.  I think that for interfaces, 
opApply has better performance.

-Steve