Roslyn: [Proposal] Better syntax for initialisers of read-only properties

[rexcfnghk]

The current C#6 syntax between _initialisers for read-only properties_ and _expression-bodied properties_ are quite similar and easily confused.

Initialisers for read-only properties

``` c#
public object Foo { get; } = new object();

## Expression-bodied properties

``` c#
public object Foo => new object();

The _syntactical_ difference may be subtle but there is a _semantic_ difference. For the initialiser, every invocation to Foo will return the same object instance; for the expression-bodied member, every invocation to Foo will return a different object instance.

I propose having a more distinctive syntax between the two constructs to avoid confusion.

[alrz]

More distinctive than that? Ö

[DavidArno]

I propose having a more distinctive syntax between the two constructs to avoid confusion.

Um, what is your proposal? At the moment you aren't proposing anything; you are just demanding someone else come up with an alternative for you.

And I completely disagree with your assertion that the syntactical difference is subtle. The two forms are already hugely different. Whilst I feel that:

public object Foo { get; } = new object();

is noisy, it does have the advantage of being clearly different to an expression-bodied property, so that noise has a benefit.

[dsaf]

@rexcfnghk Do you suggest that existing code compilation should start failing with errors or warnings? Otherwise you can simply introduce a custom comment convention:

/*!!!NOTE: EXPRESSION!!!*/ public object Foo => new object();

[rexcfnghk]

@DavidArno, I was hoping to get comments whether this is an actual problem to other people first, before I start giving suggestions to an alternative syntax. If the majority (like yourself) are disagreeing with my proposition that the syntax is confusing, why bother proposing another syntax? Please don't get me wrong, I am not demanding anything from anyone.

I think the syntactical difference is too subtle because I personally have been bitten by this more than once.

``` c#
public class Foo
{
public static Bar Bar => new Bar();
}

public class FooTests
{
[Fact]
public void Bar_ShouldReturnSameInstance_WhenCalledTwice()
{
var bar1 = Foo.Bar;
var bar2 = Foo.Bar;

    Assert.Same(bar1, bar2);
 }

}

Even with the test, it's not clear to me that I made a mistake in making `Bar` an expression-bodied property instead of a read-only property with an initialiser.

Something like

``` c#
// Expression-bodied member
public static Bar Bar => new Bar();

// Read-only property with initialiser
public static readonly Bar Bar => new Bar();

would be clearer, at least to me. But I guess everyone has their own opinion.

[svick]

@rexcfnghk

I don't see how _adding_ new syntax helps anything. It does not remove any confusion, only adds new confusion. (Why are there two ways to do the same thing? Are there any differences between them?)

[stepanbenes]

It is too late for the change. Alternative exists: do not use these features introduced in C#6.

[DavidArno]

@rexcfnghk,

Whilst I like the idea of the following being semantically identical:

public object Foo { get; } = new object();
public readonly object Foo => new object();

You haven't really fixed the problem of it being easy to forget that public object Foo => new object(); will create a new Foo every time it's called. You can't change what's already in the language and I agree with @svick that just adding a 3rd option risks confusing people more.

I think this is a training issue, rather than something to be fixed by further language changes.

[stepanbenes]

@DavidArno You got me wrong. I use these features very often and I like them. I reacted on this proposal - to change the existing syntax because it is confusing for somebody.

[DavidArno]

@stepanbenes

My apologies. Post updated to remove my attack :blush:

[jnm2]

I can say that I've used both heavily and not even once have mixed them up. => is very iconic and still makes me think "function" in my head.

[rexcfnghk]

OK, points taken. Closing the issue.