Inheritance of purity

Piotr Szturmaj bncrbme at
Fri Feb 17 06:02:37 PST 2012

Gor Gyolchanyan wrote:
> This is clearly a bug, because auto is just another way of specifying
> a valid static type.

I don't know if overriding auto makes sense at all. If you override 
something you should specify return type which is covariant with 
overrided function's one. Why would you use auto return type?

But wait... One use case where it can be helpful is overriding a 
function that return derived class and derived class is based on 
template parameter:

class A {}
class B : A {}
class C : A {}

class Test1
     A getA() { return new A(); }

class Test2(T : A) : Test1
     override auto getA() { return new T(); }

void test()
     (new Test2!B()).getA();
     (new Test2!C()).getA();

It doesn't currently compile, but if I change auto to T it does. It may 
be a compiler bug as you've pointed.

It's a simplified example, T may be not directly known (but still 
covariant to A), i.e. accesing it may be far more complex than showed by 
above example.

This is the only use case of override auto that come to my mind.

> On Fri, Feb 17, 2012 at 5:22 PM, Piotr Szturmaj<bncrbme at>  wrote:
>> Gor Gyolchanyan wrote:
>>> Aside the fact, that it's highly ambiguous, the programmers would
>>> start forgetting to write that auto :-)
>> Actually you can't override an auto function so its not ambiguous. It's
>> currently impossible to do:
>> override auto func() { }

More information about the Digitalmars-d mailing list