Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic property backing field #16926

Closed
BernardoPilarz opened this issue Feb 3, 2017 · 7 comments
Closed

Automatic property backing field #16926

BernardoPilarz opened this issue Feb 3, 2017 · 7 comments
Labels
Area-Language Design Resolution-External The behavior lies outside the functionality covered by this repository

Comments

@BernardoPilarz
Copy link

BernardoPilarz commented Feb 3, 2017

Properties are often used to do simple checks on the values that are being assigned to a member, but this requires the declaration of a backing field like so:

/// <summary>
/// Backing field for 'MyInt' property.
/// </summary>
private int _MyInt;

/// <summary>
/// Actual MyInt property.
/// </summary>
public int MyInt
{
    get { return _MyInt; }
    set
    {
        if (value < MinValue) _MyInt = MinValue;
        else if (value > MaxValue) _MyInt = MaxValue;
        else _MyInt = value;
    }
}

This has a couple of disadvantages:

  1. Having to declare the backing field is, in my opinion, verbose.
  2. The backing field can still be accessed and modified directly, bypassing completely the property (although in some cases this behavior may be acceptable).

I think the language should support automatic backing fields, which should only be accessible from the property's get and set declarations.
The backing field could reuse the 'var' keyword like so:

/// <summary>
/// MyInt property with automatic backing field.
/// </summary>
public int MyInt
{
    get { return var; }
    set
    {
        if (value < MinValue) var = MinValue;
        else if (value > MaxValue) var = MaxValue;
        else var = value;
    }
}
@per-samuelsson
Copy link

I think the language should support automatic backing fields, which should only be accessible from the property's get and set declarations.
The backing field could reuse the 'var' keyword like so:

With that, it could even be further simplified by allowing default implementation for the accessor you don't explicitly define:

public int MyInt
{
    get;  // Implicit "return var"
    set
    {
        if (value < MinValue) var = MinValue;
        else if (value > MaxValue) var = MaxValue;
        else var = value;
    }
}

@bondsbw
Copy link

bondsbw commented Feb 3, 2017

Check out #850 and #8364.

@YaakovDavis
Copy link

Unfortunately this will break existing code where a field named var exists. (With the new compiler, the new backing field will be set/read, instead of the existing field).

@BernardoPilarz
Copy link
Author

This is true. Perhaps using the keyword base could be a valid alternative? I believe base is not a valid variable name since the first C# version.

@gafter
Copy link
Member

gafter commented Feb 3, 2017

This appears to be a C# language design proposal. Language design proposals should be opened for discussion on the csharplang mailing list, and if sufficient support is given, it should be submitted as a pull request to add a proposal in markdown at the csharplang repository.

@gafter gafter added Area-Language Design Resolution-External The behavior lies outside the functionality covered by this repository labels Feb 3, 2017
@BernardoPilarz
Copy link
Author

I didn't know about the proper procedure. I'll do that now.

@gafter gafter closed this as completed Feb 3, 2017
@jnm2
Copy link
Contributor

jnm2 commented Apr 4, 2020

Using a backing field without naming it was considered in https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-04-01.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Resolution-External The behavior lies outside the functionality covered by this repository
Projects
None yet
Development

No branches or pull requests

6 participants