Question

Why is new/override required on abstract methods but not on virtual methods?

Sample 1:

abstract class ShapesClass
{
    abstract public int Area(); // abstract!
}

class Square : ShapesClass
{
    int x, y;

    public int Area() // Error: missing 'override' or 'new'
    {
        return x * y;
    }
}

The compiler will show this error:
To make the current member override that implementation, add the override keyword. Otherwise add the new keyword

Sample 2:

class ShapesClass
{
    virtual public int Area() { return 0; } // it is virtual now!
}

class Square : ShapesClass
{
    int x, y;

    public int Area() // no explicit 'override' or 'new' required
    {
        return x * y;
    }
}

This will compile fine, by hiding the method by default.

I fully understand the technical differences. However I wonder why the language was designed that way. Wouldn’t it be better to have the same restriction in “Sample 2” as well? I mean in most cases if you create a method with the same name as in the parent class, you usually intent to override it. So I think explicitly stating Override/New would make sense on virtual methods as well.

Is there a design-wise reason for this behavior?

Update:
The 2nd sample actually causes a warning. The first sample shows an error because the subclass is required to implement the abstract method. I didn’t see the warning in VS.. makes perfectly sense to me now. Thanks.

Answer 1

Using either the C# 3.0 compiler as shipped in .NET 3.5 SP1, or the C# 4.0 compiler as shipped in .NET 4.0, I get the following error for your first example:

error CS0534: ‘ConsoleApplication3.Square’ does not implement inherited abstract member ‘ConsoleApplication3.ShapesClass.Area()’

And the following warning for the second one:

warning CS0114: ‘ConsoleApplication3.Square.Area()’ hides inherited member ‘ConsoleApplication3.ShapesClass.Area()’. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.

In the first case it’s an error because you aren’t actually overriding the base method, which means there is no implementation for the abstract method in a concrete class. In the second case it’s a warning because the code is technically correct, but the compiler suspects that it isn’t what you meant. This is one of the reasons it’s generally a good idea to enable the “treat warnings as errors” compilation setting.

So I can’t repro your behaviour, and the behaviour of the compiler looks right to me. Which version of the compiler are you using?