Inheritance of purity

[Piotr Szturmaj]

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 jadamspam.pl>  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() { }