Proposal: semicolon-terminated empty-bodied void virtual methods syntax sugar

[dsaf]

It's not uncommon to have empty-bodied void virtual methods as a way of providing optional extensibility.
However at the moment they are still required to have an empty body code block:

public abstract void DoMandatoryWork(object argument);
public virtual void DoOptionalWork(object argument) {}

It's obviously a minor syntax sugar request, but it still has it's small benefits:

1. the intent is even more clear;
2. don't have to change default automatic code formatting to keep parenthesis on the same line;
3. one character less and one space less - slightly faster to read :).

Non-void virtual methods are already taken care of with expressions:

public virtual int DoOptionalWork(object argument) => default(int);

[alrz]

Also for constructors in order to change the access modifier,

public class Foo {
  private Foo();
}

For non-void virtual methods #7737 can provide an even more concise definition.

[orthoxerox]

I wouldn't mind if void was allowed to have a single value, and that value was null or something similar. This would solve so many corner cases, including this one.

[Joe4evr]

I'm not so sure, though. Just earlier today, I happened to read this question that Eric Lippert answered. He says:

There is only one kind of expression in C# which does not produce some sort of value, namely, an invocation of something that is typed as returning void.

I have no idea what the implications would be if that were to change, so I'll leave it to someone who's much more familiar with the language internals to answer that.

Unless I'm completely off the mark on what you meant.

[alrz]

I think it doesn't hurt if type inferred default (#7737) works in a expression-bodied void-returning method,

protected virtual void F() => default;

[bondsbw]

It's curious, this is allowed:

private int x;
public void set_X(int value) => this.x = value;

but this is not:

public virtual void DoOptionalWork(object argument) => ;

Not sure if that's any more helpful though.

[alrz]

Assignment is an expression, an empty statement is not.

[lachbaer]

For abstract functions and body-less constructors this is a good idea, I think! (Abstract functions already support this).

But for virtual functions, there must always be a body, even if it is empty. Because a virtual function is a valid function in a full instanciable class. It should be clear what happens if this function is invocated, even if it only returns the default value or is empty for void returning functions.

Abstract functions however may implement a body. Abstract functions make the class abstract, too (that's why the abstract modifier for the class is mandatory, to make that clear from the very beginning). And what is optional may be left out.

Also I think it is better to leave the default keyword as a 'function'. First, it is concise, not one time a 'function' another time a 'keyword'; Second, it is better to always write down, what default is returned; verbosity is one of the advantages of C#, just see the 'superfluid' abstract keyword on the before the class keyword, because it is clear that it must be an abstract class, as at least one function inside is abstract - greetings from C++ ;-)

[gafter]

Really? A language proposal to save one character?

[lachbaer]

2. don't have to change default automatic code formatting to keep parenthesis on the same line;

In VS2015 this already works for me, just typing { on the same line as the declaration puts me the } directly on the same line, nicely formatted.

I also think, the short semicolon terminated declaration should only be for external and abstract declarations. Indeed when you redefine the accessibility of a constructor - as the word says - you define something, not just declare it. A definition should always have the { } braces.

[dsaf]

I guess it's not worth it :).