I suggest you ...

Auto Properties: readonly setter, object-initializer setter

For auto properties Introduce 2 new access modifiers for the setter.

public int MyReadonlyValue {get; readonly set;}

The property can only be set in a constructor of the declaring class. Is more restrictive than private. Intended to be a less verbose way of having a readonly field.

public int MyInitValue {get; init set;}

The property can only be set within an object initialization segment
The intent of b is to improve support for immutable objects.


var myCreation = new SomeClass { MyInitValue = 10 };
myCreation.MyInitValue = 12 ; //should be compiler error!

50 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Dajo shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.
- The Visual Studio Team


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • verelpode commented  ·   ·  Flag as inappropriate

    "The intent of b is to improve support for immutable objects."
    We all know that immutable objects are very good in some situations. But how to build the immutable object? If the class contains only few properties, then a generally satisfactory solution is to pass all the properties as parameters in the constructor.

    However, this solution is impractical when a class contains many properties. A constructor with 20 parameters is impractical.

    Imagine a source code generation facility that automatically generates (and maintains) mutable "builder" (AKA "factory") versions of selected classes! It would inspect the properties of each immutable class (getter-only properties) and generate a "builder" version with the same properties except with both getter and setter methods in each property.

    It must also support collection properties. The immutable class efficiently stores each list-collection property as a fixed-size array, like this:

    private Something[] _SomeItems;
    public IReadOnlyList<Something> SomeItems { get { return _SomeItems; } }

    Whereas the builder version implements the collection property in a mutable manner like this:

    private List<Something> _SomeItems = new List<Something>();
    public IList<Something> SomeItems { get { return _SomeItems; } }
    // (still no setter, instead use IList.Add() etc.)

    IMPORTANT: I said generate the builder from the immutable class, but consider whether the opposite direction would be better. i.e. should the programmer write the builder version of the class, then the immutable version is auto-generated from the builder class. Or maybe support both directions -- programmer's choice.

    ***** ACTUALLY: The best solution may be that the programmer writes NEITHER the immutable or builder version, rather he/she writes an abstract class or interface that is used as the basis/source to auto-generate both the immutable and builder versions of the class. Perhaps the programmer can optionally override the auto-generation of a particular property implementation in either the immutable or builder class (or both) by supplying a manually-implemented version of that property (in special cases), but the default and usual situation is to auto-generate the implementation. *****

    Alternatively, you could consider some kind of new C# syntax/feature that extends the preexisting "Object Initializers" feature to better support immutable classes:

    (A bad solution: Make a constructor in the immutable class with a System.Dynamic.ElasticObject parameter, then construct the immutable object by reading the contents of the ElasticObject. This is a bad idea because it prevents IntelliSense and compile-time reporting of mistakes. It's also inefficient.)

    See also the following proposal, but I still don't think it's sensible to have a constructor with 20 parameters. The opposite direction would actually be more justifiable (if at all) -- perhaps auto-generate a constructor from properties, but certainly don't auto-generate properties from a constructor.

    Also related:

    Thanks for considering it.

  • damianh commented  ·   ·  Flag as inappropriate

    So, hasn't this been addressed with upcoming c#6? Close and give the votes back?

  • Henry Gabryjelski [MSFT] commented  ·   ·  Flag as inappropriate

    I also strongly wish that the "readonly set" property (with auto-backing field) was just part of C#. Stakx's pattern is (essentially) mirrored in so much of my code.

    Given that mutable shared data causes so many errors, it would seem appropriate to hope that immutability becomes easier to implement using C#. The "readonly set" keyword would be one of those features that is either "easy" or simply impossible due to parsing limitations... but I hope easy.

  • stakx commented  ·   ·  Flag as inappropriate

    `readonly set` auto-implemented properties are perhaps the language feature that I miss most in C#. I have written the following patterns literally thousands of times and am just *so* fed up with it:

    public SomeClass
    public SomeClass(T someProperty)
    this.someProperty = someProperty;
    private readonly T someProperty;
    public T SomeProperty { get { return someProperty; } }

    I can see where the need for `init set` properties comes from, but don't personally find them a must.

  • damianh commented  ·   ·  Flag as inappropriate

    3 vote from me. Would seriously reduce so much boilerplate code, it's not even funny.

  • Nicole Calinoiu commented  ·   ·  Flag as inappropriate

    I would love to see the readonly modifier, but I'd much prefer to require constructor creation rather than see support added for the proposed init scope.

Feedback and Knowledge Base