This is the archived version of Roland Weigelt's weblog that ran from 2003 to 2023 at weblogs.asp.net

A C# Feature I’d Really Like to See in a Future Version

In C#, if you declare a variable somewhere inside curly braces, that variable cannot be accessed from the outside. Examples are (private) member variables inside a class, (local) variables inside functions or statement blocks in general.

What I really would like to see in a future version of C# are variables that can only be accessed within a property declaration. Then it would be possible to write something like this:

class MyClass
{
    public string MyProperty
    {
        string _myProperty; // only accessible from within MyProperty

        get
        {
            DoSomething();
            return _myProperty;
        }
        set
        {
            _myProperty=value;
            DoSomethingElse();
        }
    }
}

Looks like other people had the same idea, the feature is already suggested on UserVoice. The original author of the suggestion had a different reason for the suggestion (citing documentation requirements); the benefit that I and another commenter see is the additional encapsulation. By declaring the variable the way it is shown above, you could express the intent that the backing field isn’t intended to be accessed directly, helping other people reading the code (or yourself in a couple of weeks…).

If you agree that the feature would be a valuable addition to the C# language, it would be nice if you could vote for it on UserVoice.

6 Comments

  • How would you propose the value be initialized in response to a constructor argument, especially if the property is virtual?

  • Initialization in a constructor: use the setter. Now of course there may be code in the property (or methods called from the property) that shouldn't be executed unless the instance is fully initialized - but I'd prefer to handle this with a "isInitialized" flag (that is set at the end of the constructor) instead of setting the backing field directly. It may be more verbose, but if I look at the code at a later time, I can clearly see the intent.
    Initialization of virtual properties: I haven't thought about that yet, maybe because I don't use them in my code (more a matter of personal style, not an explicit choice against using them). Calling the setter of a virtual property from the constructor of the base class isn't a good idea, for sure. So in this case you simply couldn't use the feature of an encapsulated backing field (which wouldn't be all-or-nothing anyway).

  • I like the idea, but as I understand it, the getter and setter are rendered into two different methods underneath the hood. It's not unlike asking for a variable that is only visible to two methods in a class and no others.

    That said, if the language guys can make this happen, it would be a great addition.

  • I have no doubt that the guys that brought us yield return and async await can make this happen ;-)

  • I disagree.

    Property getters and setters should not have that much logic embedded in them that they would require this feature you are after.

    If they do - why not use a proper method? It is about whether the intent of your code. Setters and getters with all sorts of logic in them fly in the face of SRP.

  • Wim, If a property has some really hard side-effects, then I agree that a method is the right choice.
    I would use the feature mostly for lazy evaluation in getters (where I want nobody to have access to the backing field).
    In setters I'd like to implement change notifications (Property Foo -> Event FooChanged) with the field hidden from others.
    In both cases having a property (instead of a method) just feels right.

Comments have been disabled for this content.