roslyn: Proposal: Expression bodied get and set methods

C# 6.0 allowed get-only properties and all methods to have an expression body. This is a great feature that can help keep the focus on business logic rather than code. However, when you need to fall back to writing a get and set method manually, it can be annoying that you’re no longer allowed to use expression bodies.

I propose supporting expression bodies for get and set methods. It makes code less verbose and also would provide more symmetry in the language.

class Foo
{
    int Bar
    {
        get => _bar;
        set => _bar = value;
    }
    private int _bar;
}

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 7
Comments: 30 (22 by maintainers)

Links to this issue

Most upvoted comments

@fedeazzato I understand what you mean, but a new topic for that would be more appropriate in my eyes. Nevertheless, you suggest to delegate a property to an internal field, like you could do with methods:

class Foo {
    private OtherClass oc = new OtherClass();  // has int BarMethod();
    public int BarMethod() => oc.BarMethod();
}

For fields it would be something like:

class Foo {
    private OtherClass oc = new OtherClass();  // has int BarProperty { get; set; }
    public int FoosProperty <=> oc.BarProperty;
    // I'd rather use a syntax like:
    public int FoosProperty { get; private set; } => oc.BarProperty
   // allows arrow operator after get; set;
}

But, I am not a friend of this! Properties are somehow like fields, just with get/set/access field control. In terms of clean programming it wouldn’t be a great idea if you could delegate a field:

/* discouraged example */
class Foo {
    private OtherClass oc = new OtherClass();  // has int BarField = 0;
    public int FoosField <=> oc.BarField;
    /* <=> operator delegates to oc.BarField; */
}

Well, it looks okay, but is really, really messy!

@Ziflin (also) Having played around with Java in the last time (mea culpa 😉 I have to admit that strictly seperating properties into getter and setter methods - what internally they are - is a really good idea from the viewpoint of readability and understandability. You can clearly use access restrictions and attributes on either of the methods, setter or getter. Never combine getter and setter for reasons of abbrevation in code!

My conclusion: there sould be no <=> operator at all, that delegates or links properties or fields. Hiding fields by properties is an established practice and properties consist of getter and setter methods, which should not be hided further.

PS: #15708 is okay, but that is Visual Basic 😉

lachbaer on Dec 16, 2016

@lachbaer We discussed this at the LDM today, and we are supportive of this, but we’d prefer to support all relevant contexts when we do this. In particular, we’d like to add constructors and destructors to the list of things that can have => bodies. Are you motivated to do that?

gafter on Mar 3, 2016

@Ziflin That is not a bug. If you need to place an attribute on the getter (but not on the property itself), you can’t use the shortest form.

gafter on Dec 16, 2016

I’m not sure if this is the right place to bug this, but the following should be legal in C# and it’s currently not:

[MethodImpl( MethodImplOptions.AggressiveInlining )] // <-- Error
public float Length => Math.Sqrt( X * X + Y * Y + Z * Z );

This results in:

Error CS0592 Attribute ‘MethodImpl’ is not valid on this declaration type. It is only valid on ‘constructor, method’ declarations.

Method attributes should be allowed on getter-only expression-bodied properties as the following is allowed:

public float Length
{
    [MethodImpl( MethodImplOptions.AggressiveInlining )]
    get => Math.Sqrt( X * X + Y * Y + Z * Z );
}

Ziflin on Dec 16, 2016