Void virtual methods with no body

[iikuzmychov]

Background and Motivation

Quite often, developers encounter the need to create an empty virtual method to allow derived classes to override it only if required. But it is very uncomfortable and ugly looking.

Proposed API

The proposal suggests extending the Roslyn API to allow the declaration of void/Task virtual methods without bodies.

Example:

public abstract class BaseClass
{
    public virtual void Setup()
    {
        // setup logic
        AdditionalSetup();
    }

-   protected virtual void AdditionalSetup() { }
+   protected virtual void AdditionalSetup();
}

public class DerivedClass : BaseClass
{
    protected override void AdditionalSetup()
    {
        // additional setup logic
    }
}

[TahirAhmadov]

The reduced typing just isn't worth it, even with => Task.CompletedTask;, let alone with {}, given the amount of work it takes to make a language change.

[orthoxerox]

//method intentionally left empty is the best way to clarify the developer's intent.

[iam3yal]

@svick You're right, didn't think about it that way.

[iikuzmychov]

For methods, no body (;) means that if you invoke the method, the body comes from somewhere else

@svick Not really, actually partial, extern and abstract modifiers tell us about it

[DavidArno]

@orthoxerox,

//method intentionally left empty is the best way to clarify the developer's intent.

I disagree. Comments are always the worse possible way of clarifying intent and are a method of last resort when the language doesn't allow intent to be expressed in code.

But I really don't like this proposal. To me the intent is already clear:

protected virtual void AdditionalSetup() { } // Has default behaviour of doing nothing. Override if you wish
protected abstract void AdditionalSetup(); // Has no default behaviour. You have to override

And no, the irony of using comments here to explain them is not lost on me 😆

@iikuzmychov ,

@svick Not really, actually partial, extern and abstract modifiers tell us about it

Don't forget record too. You and svick are both right: the lack of body says the details are elsewhere and the keywords tell us where.

[jnm2]

In the same sense that the abstract keyword tells you the implementation comes from somewhere else, the implementation comes from somewhere else for interface methods which have no (required) keyword to tell you so.