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<bncr...@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() { }

Reply via email to