I can comprehend braces faster than I can read the word "get". Sometimes structural code is useful as a navigation and comprehension aid. I've been doing a lot of python lately and I am much slower at scanning a file to find a piece of code or understand its structure precisely because everything is just words. This recent trend towards naive minimalism in language design is awful.

public int X { get; } is more consistent with how properties are declared. Consistency is important.

If you care about clean code, here's an even better way public readonly int X; They are not exactly the same but they are equivalent in most cases. In exotic cases where you're required to use auto-getters, adding the brackets wouldn't hurt.

> public int X { get; } is more consistent with how properties are declared. Consistency is important.

As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc.

The braces are for scope in C# and all C derivative languages. There is no scope being created here and no requirement for scope. Also there are other places in C# where the scoping braces can be dropped [when there's only a single statement within]:

    if(foo == 1)
    {
       bar();
    }

Can be written:

    if(foo == 1)
       bar();

So I don't see the inconsistency at all if they were to drop the braces.

> If you care about clean code, here's an even better way public readonly int X

That's what I use. Cue the next round of discussion about fields and properties...

>As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax?

They did change the property declaration syntax too.

    public int X => 5;

is the same as

    public int X { get { return 5; } }

This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about.

Of course it isn't identical to public int X { get; } because the latter is assignable in the constructor. But comparing _that_ to methods is apples to oranges since methods aren't assignable.

I think you're quoting me out of context here. I am debating the consistency angle. My argument is that if there is such a drive for consistency (and therefore that's a good reason to keep the braces) then the method syntax wouldn't have changed to drop the braces. So I feel that argument is moot when discussing the reason for keeping the (what I believe to be) ugly syntax of X { get; } = 5;

Your example of the computed properties is not the same. I like the computed properties syntax, but unless the properties can be computed from the constructor parameters then you will still need to either use the ugly property syntax, or readonly fields to get the same immutable guarantees.

Personally I am fine with using readonly fields, I was only commenting on how the C# team have (in my opinion) missed the opportunity to get rid of some of the unnecessary clutter. I know however many people don't like using readonly fields for various reasons: serialisation, data-binding, interface declarations, etc.

Because people like braces (they provide structure) and there is a risk to break backward compatibility. Granted the whole ;} = 5; syntax is not great ....

That must be why they removed the need for braces with 'lambda' methods right?

It just seems so pointless and ugly, no one is going to write them like this (well, seems unlikely anyway):

    public int X 
    {
        get;
    } = 5;

So they're no longer providing a scope/block structure. How would it break backward compatibility? I'm not suggesting they remove the scoping for properties, it's clearly needed for {get;set;}, but as far as I can tell I can't think of any existing property-name suffix keyword in the C# grammar, so it seems it wouldn't be too hard to get it to work.

The only reason I can think of to not do it is to reserve the option of post property-name keywords for future features.

I've been using public readonly fields instead for a number of years now because of the constant boilerplate. I doubt I'll change to use these auto-properties for the same reasons.

For the second one you can write this:

    public int Y => 5;

It isn't the same. With immutable properties the constructor can change the value of Y based on its own decision logic. So 5 is just a default and the constructor may change it. That allows for multiple constructors, some that set the value some that don't.

If the value is always going to be 5, then use a const.