Can we get rid of opApply?

[Denis Koroskin]

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();
}