Field keyword in properties: directly assign backing field in constructor

[whiskhub]

TLDR: It should be possible to assign the backing field of a property using the field keyword from the constructor.

One use case of the new field keyword for properties is INotifyPropertyChanged properties (e.g. in WinUI, WPF).
The .NET Community Toolkit goes even further and allows source generated partial properties that use field in the generated code.

One limitation with the field keyword is however, that it is no longer possible to initialize the backing field using a non-constant value without invoking the custom setter code. The setter code could i.a. contain a property changed event or logic to update the value in a database.

This is especially undesirable in the constructor, when you for example want to initialize the property from a constructor-injected database object, but without it re-saving the value to the database again:

internal partial class MainViewModel : INotifyPropertyChanged
{
    private readonly IDatabase _database;
    
    public MainViewModel(IDatabase database)
    {
        _database = database;

        // this will call the setter and write the value back to disk 
        MyProperty = _database.ReadFromDisk();
    }

    public string MyProperty 
    { 
        get; 
        set
        {
            if (value != field)
            {
                value = field;
                _database.WriteToDisk(value);
                OnPropertyChanged();
            }
        }
    }
}

However, today it is already possible to assign parameters from a primary constructor to a property with a field keyword:

internal partial class MainViewModel(IDatabase _database) : INotifyPropertyChanged
{
    public string MyProperty
    {
        get;
        set
        {
            if (value != field)
            {
                value = field;
                _database.WriteToDisk(value);
                OnPropertyChanged();
            }
        }
    } = _database.ReadFromDisk(); // this does not call the setter
}

This feels like a gap in the language that should be resolved IMO.

[HaloFour]

IIRC writing to the property from the constructor has always invoked the setter accessor method, with the one exception of readonly auto-properties where there is no setter accessor method. IMO, bypassing the setter in this case would be just as surprising as it could be expected to validate input received in the constructor.

[HaloFour]

If you wanted to be able to access the backing field directly from outside of the scope of the property, why wouldn't you just declare a normal property and a backing field?

[whiskhub]

Yes, but from the context of CommunityToolkit/dotnet#993 this would make the feature near useless for a lot cases, having to fall back to backing fields. Is there ever a use case to have a viewmodel property in MVVM that is not initialized to the value of the model?

Your point is valid for outside of the constructor, there I would agree it makes sense to just add a field manually again.

[whiskhub]

And the fact that it works using a primary constructor feels like it is an unnecessary limitation for regular constructors.

[CyrusNajmabadi]

And the fact that it works using a primary constructor feels like it is an unnecessary limitation for regular constructors.

Similar to what i mention below, this is unrelated to field. This is an aspect of property initializers vs assignments elsewhere. The initializer writes to the backing field, the constructor does not. This is true today with auto-props (even before 'field').

[CyrusNajmabadi]

However, today it is already possible to assign parameters from a primary constructor to a property with a field keyword:

Note: this is not about the field keyword. It's possible to assign primary constructor parameters to any auto-prop (not just field based ones).

[CyrusNajmabadi]

I'm not sure what is being asked for here. There isn't an actual proposal that addresses the concern raised in the OP.

Note: a constructor not being able to assign into an auto-prop directly is already a limitation in the language, even prior to 'field'. For example:

class C
{
	virtual int Prop { get; set; }

    public C()
        => this.Prop = ...;  // doesn't access the field.
}

field doesn't change this.

[whiskhub]

You are right, there was this limitation before field already. But with this new field keyword the limitation becomes more prominent, at least for my use cases. The suggestion in #8704 (comment) would be a potential solution.

[jnm2]

It seems like the ask is for ordinary constructors to be able to run code based on constructor parameters and initialize the property's backing field directly, just like primary constructors can.

What if we could "teleport" the = initialValue; from the property declaration to the constructor? The teleportation could be invoked with a syntax such as init Prop = expr:

class SomeViewModel
{
    public SomeViewModel(int value)
    {
        // [extra statements] here
        init SomeProp = SomeCalculation(value);
    }

    public int SomeProp { get; set => { field = value; RecalculateAndUpdate(); } }
}

This would maintain equivalence with what is possible with primary constructors today, while also allowing you the benefits of being able to add statements to the constructor which you cannot do with primary constructors today:

class SomeViewModel(int value)
{
    // But no place for [extra statements]!
    
    public int SomeProp { get; set => { field = value; RecalculateAndUpdate(); } } = SomeCalculation(value);
}

[jnm2]

Ironically, this demonstration of using a flag also demonstrates the downside of dealing with additional state tracking like such a flag. (the setter is not correctly implemented)

[HaloFour]

(the setter is not correctly implemented)

Indeed it's not, but it also wasn't correctly implemented in the OP. I was tempted to point that out, but decided not to. Makes me wonder how often people will assume that the backing field will be assigned automatically by the set accessor?

[jnm2]

Ah, I see now. I think it make the example hard to appreciate :D

There's a warning on the setter, so people will likely notice right away.

⚠️ CS9266 The 'set' accessor of property 'SomeClass.SomeProp' should use 'field' because the other accessor is using it.

[whiskhub]

I would've noticed in the IDE, but I wrote the code on GitHub markdown and missed the value assignment... Interview failed 😅

[AartBluestoke]

class SomeViewModel
{
    public SomeViewModel(int value)
    {
        // [extra statements] here
        init SomeProp = SomeCalculation(value);
    }

    public int SomeProp { get; set => { field = value; RecalculateAndUpdate(); } }
}

what if, only inside a constructor, you could use 'field' in place of data type and write the following to indicate that you were bypassing the set call?

 class SomeViewModel
 {
     public SomeViewModel(int value)
     {
         // [extra statements] here
         field SomeProp = SomeCalculation(value); // equivilant to calling a set operator that is only {field = value;}
     }
 
     public int SomeProp { get; set => { field = value; RecalculateAndUpdate(); } }
 }

[HaloFour]

To be honest, I find it really weird that semi-auto-properties allow for initializers at all, and that such an initializer bypasses the set accessor. I'd argue that it shouldn't be permitted, unless either the semi-auto-property did not have a set accessor, or it was an empty set accessor. Bypassing the logic of the accessor feels very wrong to me.

[jnm2]

Not only is the choice constrained by history (observable difference with virtual auto props), but it's been practically useful in my own development experience as well. Here's where the proposal discusses it: https://github.com/dotnet/csharplang/blob/main/proposals/field-keyword.md#property-initializers

[RikkiGibson]

I opened #9028 to try and articulate why I think this use case matters and how to address it.

[dersia]

In general I like this idea a lot, but fieldof() = value; doesn't feel right.
it reads like typeof(), nameof() and those are readonly.
Also fieldof(), feels like you could . into it as if it would return something, if you wouldn't assign something to it. and if this is the case what would it actually return? if it would return the field, what can you do with it? or does it only return the value of the field and it is a way to access the field's value by bypassing the getter? this could also be a feature and that might be something we want. I am just asking the question if this is something we need to address.

[RikkiGibson]

A fieldof() expression is a special form of a field access. The expression is classified as a variable, etc., so you can read it, assign it, take a ref to it, and so on. Just like if you used obj._field to refer to an ordinary field.

[weitzhandler]

There must be a way to mark the field as readonly!

For example:

class Foo
{
    public Foo()
    {
        fieldof(Prop) = 5; // fine
    }

    public SomeMethod()
    {
        fieldof(Prop) = 5; // compile error - field is read only
    }

    [field: ReadOnly]
    public object? Prop { get; }
}

[weitzhandler]

I see now it's part of the spec, great!

[Thaina]

This is great feature, however it should also come along with feature to convey limitation intention

Also what would happen if the property has no backing field at all?
What would happen if we try to use it on interface or abstract property?

[mmkiwi]

I'd definitely use this feature in ViewModels for a project I'm using that has ReactiveUI and DynamicData. I just refactored one of my ViewModels to take advantage of field-backed properties to clean up having as many backing properties in scope.

Old Code

public class ViewModel
{
    public ViewModel()
    {
        _someCollectionSourceList
            .Connect()
            .Bind(out _someCollection)
            .Subscribe();
    }
    protected readonly SourceList<string> _someCollectionSourceList = new();
    protected readonly ReadOnlyObservableCollection<string> _someCollection;
    public ReadOnlyObservableCollection<string> SomeCollection => _someCollection;
}

Current Code

public class ViewModel
{
    public ViewModel()
    {
    }
    protected readonly SourceList<string> _someCollectionSourceList = new();

    [field:MaybeNull]
    public ReadOnlyObservableCollection<string> SomeCollection
    {
        get 
        {
            if(field == null)
                _someCollectionSourceList
                    .Connect()
                    .Bind(out _someCollection)
                    .Subscribe();
            return field;
        }
    }
}

If this proposal was implemented, I could get rid of field-backed properties entirely and switch to

public class ViewModel
{
    public ViewModel()
    {
        _someCollectionSourceList
            .Connect()
            .Bind(out fieldof(SomeCollection))
            .Subscribe();
    }
    protected readonly SourceList<string> _someCollectionSourceList = new();
    public ReadOnlyObservableCollection<string> SomeCollection { get; }

PS: The collections are protected so I can subclass them and inject some fake data while working with the UI previewers. It would be great to be able to use fieldof in the constructor of a derived class like the following. I could see base classes needing to opt in to that behavior somehow since it'd bypass any logic in the setter.

public class DesignTimeViewModel: ViewModel
{
    public DesignTimeViewModel()
    {
        GetSomeDesignTimeData()
            .Connect()
            .Bind(out fieldof(base.SomeCollection))
            .Subscribe();
    }
}

[RikkiGibson]

We wouldn’t permit ‘fieldof(base.Prop)’, for a few reasons, but one is that we don’t want a type to take a dependency on whether another type uses backing fields or not.

Similarly, a constructor cannot assign a readonly field declared in the base, only the base constructor can do that.

[RikkiGibson]

I added an alternative Permit anywhere in the same type to the proposal for discussion purposes. This isn't the approach that I am proposing, but it seems like reasoning out the implications of this alternative would be useful.

[whiskhub]

There are cases in MVVM where you want to distinguish whether a value was set from the UI or from the code. In such cases, you wouldn't want to execute the usual setter code but only raise an INotifyPropertyChanged event.

For example, you have a volume float property. When the slider is dragged in the UI, the model should be updated with the new volume. However, the model might also update the volume independently, in which case you update the VM property with the new value, but you don't want to re-update the model with the same value again (to avoid potential recursive loops due to floating-point number equality). Or you want to debounce the value, ...

A fieldof keyword outside the constructor could be helpful here. Nonetheless, I agree that these are very specific use cases, mainly caused by limitations in the MVVM Toolkit Source Generator (which are sensible, to avoid feature creep) and could be solved otherwise (manual backing field, better equality checks in model, ...) without a new language keyword.

[jaredpar]

Allowing it anywhere would remove one of the primary reasons why I have to convert auto-implemented properties to manual ones today: the need to pass data by reference. Having fieldof everywhere would allow me to keep using auto-implemented or field backed properties but still drop down to ref uses where needed within the type.

[RikkiGibson]

One scenario which is giving me pause here is:

class C
{
    public string Prop1 { get; }
    public string Prop2 { get => field ??= "a"; }

    void M()
    {
        fieldof(Prop1) = "b";
        fieldof(Prop2) = "c";
    }
}

What happens here?

• It feels like we would need to permit the write for Prop2. Clearly the field is mutable. In the field design we decided the mutability of such backing fields is valuable.
• So, shouldn't we also permit the write for Prop1? But that seems to break the "readonly-ness" that users grew to expect for such properties.
• If we disallowed the write for Prop1, then it seems like changing its definition from { get; } to => field; would cause an "arbitrary" difference here, when mostly we think those definitions should work as similarly as possible.

[TahirAhmadov]

Is it arbitrary though? The usage of the field keyword is a meaningful difference, no?

[sab39]

My intuition on reading that code - before reading the bullet points below - was that it should be legal for Prop2 but not for Prop1. But I also share the intuition that there should be no difference between string Prop1 { get; } and string Prop1 => field;. To my mind the key difference is the fact that the Prop2 getter actually modifies the field's value. I think my expectation would be that the compiler should emit the field as readonly by default, unless there's code in an accessor that modifies it.

[hez2010]

The proposal fieldof seems pretty weird and confusing to me.
When I see fieldof, I would expect the operand to be a field and the return value to be a FieldInfo, just like what we have for typeof.
IMO we should choose another keyword for this, or don't do this at all.
One can always declare a field for assignment instead of using an automatically implemented field keyword. I don't think it's worth introducing a confusing feature just for some niche usage that you can simply achieve by typing a few more characters. Not to say this feature would only work with auto fields, which is extremely limited.

[jnm2]

I would not expect fieldof(someExpr) to return a FieldInfo object. I would expect it to access a field. If XyzInfo is returned, I want to see 'info' in the operator name: infoof(someField)
infoof(SomeProperty)
etc

[TahirAhmadov]

I agree with @hez2010 on this. Perhaps something like Prop::field would work better.

[RikkiGibson]

At the moment, I am thinking that while this issue represents an unfortunate limitation, it's not currently at the level to justify a language feature to fix it. Possibly in the future, either we will start seeing a greater urgency for this, or, another more general feature will come around which gives us an opportunity to address this scenario at the same time.

Please let us know if you are impacted by this. I'm interested to hear from people who have to compromise on other coding patterns, in order to fit into the current pattern with primary constructors and property initializers, or who just can't adopt that pattern and need to declare a bunch of backing fields, etc. Thanks!

[whiskhub]

I've already mentioned my use cases, which mainly involve ViewModels in MVVM and the CommunityToolkit source generator (CommunityToolkit/dotnet#993). Without fieldof or a similar feature, I will have to continue using the previous field approach with the source generator, unless the maintainers rethink their position and change their implementation. With the introduction of the field keyword, it may however become cleaner to write the properties on your own without using the source generator at all. It's one step forward but two steps backward in terms of usability, as it leads to the loss of some nifty features of the source generator like NotifyPropertyChangedFor or partial Changed methods.

I do not particularly like primary constructors because you can't set the parameters to readonly and you lose the ability to run code in a "normal" constructor. I would not use them in the majority of cases.

In the larger picture, if fieldof wouldn't just be limited to constructors, it could also allow the complete elimination of any property with a manual backing field.

[colejohnson66]

Yep. Any reactive system that uses source generators suffers from needing to emit fields if you want to avoid change notifications from the constructor.

[sab39]

Not sure if there are existing features that this would conflict with, but I wonder if using the ref keyword might make sense here? I'm not well versed in all the meanings of ref today (except for the in/out/ref modifiers on method parameters that have existed since C# 1.0) so maybe this idea is fundamentally inconsistent with established semantics, but on some level ref has an association with raw, direct access to something that would normally have a layer of indirection, which would fit with getting at the raw underlying field of a property.

[hez2010]

Another issue of this proposal is that you should NEVER know the backing field of a property outside the property itself, as it's an implementation detail of the property. fieldof(Prop) simply breaks this rule, and it will never work for cases other than auto-implemented properties, which seems pretty fragile to me.

An alternative could be reuse init so that we have:

int Prop
{
    get => field;
    set => ...;
    private init => field = value;
}

Then all assignments to Prop in the ctor call init instead of set. And this won't be a breaking change as we didn't allow set and init to coexist before.

[RikkiGibson]

The fact that a property has a backing field is already leaked to constructors, when the property lacks a set/init accessor.

class C
{
    public C()
    {
        Prop1 = "a"; // ok
        Prop2 = "b"; // error
    }

    public string Prop1 { get => field; }
    public string Prop2 { get => "c"; }
}

[HaloFour]

Sorta, the constructor is writing to the field directly but from the language perspective it's just a write to the property itself. You can't take a ref to the backing field, for instance. It's more like a private readonly set accessor as otherwise it'd be impossible to keep the property an auto-property and readonly.

[RikkiGibson]

What I am really pushing back on here, is the absolute statement, that usage of field should never "leak out". It is a reasonable philosophy, that using field is a decision local to the property, and doesn't affect the rest of the type. It's a good default position in terms of the design and how it interacts with the rest of the language. But there are all sorts of reasons it isn't true on an absolute basis.

[CyrusNajmabadi]

i definitely don't view it as true. It's 100% owned by the type. Anything else can't take a dep on it. But the type itself is certainly potentially privy to this (Esp. in the constructor).

[weitzhandler]

To me it makes sense not having direct access to the field, I see the issue more in fine-tuning and separating init and post-init logic. Posted comment here: #8704 (comment).

[rudolfstepan]

I had a similar idea to a fieldof(..) syntax. The original discussion was closed to be duplicate to this. #9511 (comment)

To be short:

I'm not strictly attached to the name fieldof.
It simply felt like the natural choice, given how it mirrors nameof and is conceptually tied to the existing field keyword introduced in C# 12 for auto-properties.

My goal is not to expose arbitrary fields or bypass property logic recklessly, but to give developers a clean and controlled way to access the compiler-generated backing field (e.g. <>Price) – the same field that already exists under the hood for auto-properties.

This would allow us to:

• continue using the modern get; set; syntax,
• benefit from the simplicity of auto-properties,
• and still have precise control where necessary (e.g. silent state updates, undo/redo, deserialization),
  without giving up on this great language feature just because we occasionally need to bypass the setter logic.

If there’s a better or more idiomatic way to achieve this behavior while retaining auto-properties and compiler-generated fields, I’m absolutely open to suggestions.

I simply want a way to combine the elegance of auto-properties with the flexibility of manual field control – in a safe, compiler-approved manner.

Example:

set => field = value; // already allowed

// ...
fieldof(this.SomeProperty) = value; // same idea, outside property

[jnm2]

The proposal issue is not linked anywhere in this thread, so here it is: #9031
From there, you can get to the design meeting links, as well as the current proposed specification.

[weitzhandler]

How could we choose to assign field directly in init properties, only when initializing but not post-initialization?

var myRecord = new MyRecord { MyInitProperty = 5 };

...

public record MyRecord
{
    public int MyInitProperty { get; init; }
}