Declarative empty statement; Drop brackets for ctor and void methods with empty bodies

[kingces95]

Small suggestion. In place of

class Foo {
    Foo() : this(0) { }
    Foo(int i) { }
}

allow

class Foo {
    Foo() : this(0);
    Foo(int i) { }
}

or maybe (scratch this idea)

class Foo {
    Foo() => this(0);
    Foo(int i) { }
}

[jnm2]

This has kinda bothered me too.

(You might not want to distract people by declaring a default struct ctor, that's a different discussion 😁)

[svick]

Related: dotnet/roslyn#17306, #181, #208.

[kingces95]

@svick Thanks for the x-reference. Should I close this? #181 and #208 are composite issues. Unless I get admonished, I'll keep this issue open as sometimes babies get thrown out with bath water when multiple suggestions are grouped into a single issue.

[svick]

@kingces95 I don't think you should close this (unless there is another duplicate that I missed). dotnet/roslyn#17306 is in the wrong repo and #181 and #208 were closed by the author, in the second case because he thought separate issues (like this one) are better.

[DavidArno]

@svick,

Just to clarify, I preferred lumping the three together, but closed #208 as most others seemed to prefer the idea of individual issues for the three topics. But I agree this one should be kept open.

[Joe4evr]

Please also for base:

class Bar : Foo
{
    public Bar(int i) : base(i);
}

However, I'm opposed to having Foo() => this(0); since using => makes an "expression-bodied member" and this()/base() is not part of the constructor body.

Additionally, the two should be able to blend, IMO:

public Bar(int i, string s) : base(i)
    => _s = s ?? throw new ArgumentNullException(nameof(s));

[svick]

@Joe4evr

Additionally, the two should be able to blend, IMO:

public Bar(int i, string s) : base(i)
    => _s = s ?? throw new ArgumentNullException(nameof(s));

That's already valid C# 7.0 code.

[Joe4evr]

Ah yeah, I forgot to make the point that we shouldn't introduce parsing complexity (for both compiler and user) by allowing:

public Bar(int i, string s)
    => base(i)
    => _s = s ?? throw new ArgumentNullException(nameof(s));

[jnm2]

Yes, definite veto on the => this(...) or => base(...) syntax.

[HaloFour]

I think that I'd only want this syntax if it could be supported across the language, e.g. with normal methods:

public class Foo
{
    public virtual void Bar(); // does nothing
}

My concerns there would be that it could be confusing when writing abstract types.

Also, with properties the lack of a body already means something, which could also be confusing.

[kingces95]

@HaloFour Yep, without extending the syntax to all { } there's an asymmetry and I doubt the powers that be will allow for dropping { } on void methods to fix that asymmetry. So that'll prob sink the idea. That said, every time I implement IEnumerator<T> with public void Dispose() { } I secretly wish I could write public void Dispose();.

It just seems a shame that C# has moved in a more declarative direction with the introduction of => and yet does not have declarative syntax for "do nothing" and instead requires me to write procedural code to express "do nothing".

[Joe4evr]

I think that I'd only want this syntax if it could be supported across the language

I had actually considered a post about generalizing this to other empty blocks, but I was turned off when someone said they didn't want to have it for a catch blocks: catch (OperationCanceledException);

[kingces95]

@Joe4evr Yeah, I'd agree that catching an exception and doing nothing is a turn off. However, if someone's gonna do it I'm not sure catch (OperationCanceledException); is more of turn off than catch (OperationCanceledException) { }.

I guess I'd say that making an ugly convention easier to write (empty exception handlers) is just the other side of the coin to be paid to make the boilerplate conventions easier to write (empty ctors and interface implementations).

[Joe4evr]

Yeah, I can see the case for not allowing it on empty catch blocks, so I guess that's the price for having only one way to deal with cancelling an async operation. ¯\_(ツ)_/¯

[Thaina]

Also, with properties the lack of a body already means something, which could also be confusing.

I don't think so. () is clearly said "this is function" already

[jeme]

This also annoys me from time to time with constructors, so certainly in favor.

I think that I'd only want this syntax if it could be supported across the language, e.g. with normal methods:

@HaloFour Yep, without extending the syntax to all { } there's an asymmetry and I doubt the powers that be will allow for dropping { } on void methods to fix that asymmetry. So that'll prob sink the idea. That said, every time I implement IEnumerator with public void Dispose() { } I secretly wish I could write public void Dispose();.

I wouldn't be opposed to extending the syntax to methods as well, but functionally they would be quite different in behavior:

If we look at the example for a constructor, we are doing something as we are calling another constructor, that constructor then does some things.

public MyType() : this(new DefaultFoo());
public MyType(IFoo foo) => this.foo = foo;

With the method example, that is quite in contrast not doing anything:

public virtual void MyMethod();

So I would argue that for methods, functionally the behavior proposed here would be more in line with this example where one method calls another overloaded method (virtual methods or not):

public void MyMethod() => MyMethod(42);
public void MyMethod(int number) { ... }

Which as we can see, expression bodies already makes cleaner.

If the syntax was extended to all { }, then turn that around on constructors again, I wouldn't want to allow this:

public MyType(); // Pointless default constructor...
public MyType(IFoo foo); // Pointless constructor that takes an argument???...

Nor would I wan't to allow these pointless case either:

public void Dummy(); // In cases where it does not come from an interface...
public static void Dummy(); // Pointless static method... 

etc.

---

That is not to say that the virtual method case isn't interesting as well, but it's just functionally different.

[Tylertron1998]

Sorry to bump an old issue - could we get an update on this? It'd be great to see what people think and if it's a possible addition to the language or not. I really do prefer to not have empty curlies - it's a completely personal distaste, but there also seems to be a lack of proper styling guides within the community, some do {} next to the method deceleration, some do it on the next line.

I don't want to speak on behalf of the language designers/implementers, as i have 0 say here, but it seems a harmless, small, and (fairly) easy change to make, although please correct me if I'm wrong.

[HaloFour]

@Tylertron1998

It hasn't been championed by a language design team member so it's not really going anywhere. I don't expect that they'll consider anything new until after C# 8.0 ships.

[Thaina]

@jeme Not so pointless for

public override void Dummy();

And also a method that would meant just for implement interface but want it to do nothing

[gafter]

We cannot do this, at least not for normal methods. Here's why.

As part of the "default interface implementation" feature, we're supporting concrete methods in interfaces. So you can write

interface I
{
    void M() { }
}

In this case, the method is virtual rather than abstract.

Clearly this means something different from

interface I
{
    void M();
}

in which the method is abstract not virtual.

Since we cannot do as suggested in interfaces, it would be supremely confusing to do it in classes. Consequently, we won't do it.

[HaloFour]

@gafter

In this case, the method is abstract rather than virtual.

I think you got those backwards?

[gafter]

Yeah, fixed.

[jeme]

@jeme Not so pointless for

public override void Dummy();

And also a method that would meant just for implement interface but want it to do nothing

I didn't say that, I just stated that for methods it would be functionally different to whats proposed here...
And if including that there was some cases to watch out for that wouldn't make sense.. The example you give was not one of those examples.

To be fair though... I did mention the following example to be pointless:

public void Dummy();

Where your right... That could actually make sense when your implementing an interface... That was an oversight. I added a note about that it would only be pointless if it didn't come from an interface.