Proposal: field keyword in properties

[lachbaer]

Proposal: field keyword in properties

(Ported from dotnet/roslyn#8364)

Specification: https://github.com/dotnet/csharplang/blob/main/proposals/field-keyword.md

LDM history:

• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-03-10.md#field-keyword
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-14.md#field-keyword
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-01-12.md#open-questions-for-field
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-02-16.md#open-questions-in-field
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-02.md#open-questions-in-field
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-21.md#open-question-in-semi-auto-properties
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-05-02.md#field-questions
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-26.md#ungrouped
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-10-12.md#keywordness-of-field
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-05-15.md#field-and-value-as-contextual-keywords
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-06-24.md#field-questions
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-07-15.md#field-keyword
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-08-14.md#field-keyword
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-08-21.md#field-keyword-nullability
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-08-26.md#field-keyword-open-questions
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-18.md#nullability-in-field

[scottdorman]

This could also be useful/part of the implementation for #133.

[HaloFour]

My opinion is that this proposal makes auto-implemented properties more difficult to read by introducing these silent backing fields despite the use of logic. With expression-bodied accessor members a chunk of the boilerplate for standard properties already disappears. The IDE eliminates much of the rest via standard code snippets.

[lachbaer]

Suggestion:

• only allow setters to be defined in auto-properties (making them semi-auto)
• this setter expects the value to be assigned as a return value
• to set it in the middle of the block, yield return is used.

int ASemiAutoProp
{
    get;
    set
    {
        var pcea = new PropertyChangeEventArgs(this.ASemiAutoProp, value));
        OnPropertyChanging( pcea );
        yield return value;
        OnPropertyChanged( pcea );
    }
}

Then there is no need for a new field keyword/variable.

And the following really looks better than with #133

public T PropertyInitialized
{
    get;
    set => value ?? new ArgumentNullException();
} = default(T);

instead of (with #133) - a bit much of backingField.

public T PropertyInitialized
{
    T backingField = default(T);
    get => backingField;
    set => backingField = value ?? new ArgumentNullException();
}

[lachbaer]

Instead of using a field keyword, I also suggest following syntax borrowed from C struct:

public string FirstName
{
    get;
    set => _name = value;
} _name;

_name is by definition private to it's type (maybe unless directly prepended by an access modifier?).
OR just scoped to the corresponding property, what would even be better.

In case expression-bodied set of semi-auto-properties expect a value being returnd to assign to the backing-field (here with additional initializer):

public string FirstName
{
    get;
    set => value;
} _name = "(not set)";

This completely eradicates the need for a field keyword or yield return as suggested above, because now the backing field's identifier can be used

public string FirstName
{
    get;
    set {
        var pcea = new PropertyChangeEventArgs(_name, value));
        OnPropertyChanging( pcea );
        _name = value;
        OnPropertyChanged( pcea );
    }
} _name = "(not set)";

This would also go hand in hand with #133.

[HaloFour]

@lachbaer

With the declaration of the field being outside of the property block that would imply that the scope of that field would be for the entire class, not for just that property. That's also consistent with the scoping of that C syntax.

[lachbaer]

@HaloFour
Sure, but in this case we could probably rely on IntelliSense not to spoil the rest of the module.
Also without any prepending modifier it would imply internal access. (corrected, of course class members are private by default) 🙄
But nevertheless, I think that this is a neat way to achieve at least some of the goals.
Also the costs of implementing it could be reasonable.

[lachbaer]

Of course specifying a getter only works, too:

public string FirstName
{
    get {
        Debug.Assert( _name != null, "Getting name before setting it?");
        return _name;
    }
    set;
} _name = null;

or combined:

public string FirstName
{
    get {
        Debug.Assert( _name != null, "Getting name before setting it?");
        return _name;
    }
    set => value ?? throw new ArgumentNullException();
} _name;

In the latter example, just specifying the _name identifier qualifies for a semi-auto-property and therefore for set => value .

[jnm2]

@HaloFour

My opinion is that this proposal makes auto-implemented properties more difficult to read by introducing these silent backing fields despite the use of logic.

I don't disagree with your whole comment, but I wanted to point out that the difficulty reading is only if you're accustomed to thinking of logic and automatic backing fields as mutually exclusive. I don't think they should be. It's not hard to learn to look for a field keyword. It'll be right where you'll look if you're looking for the backing field anyway.

The reason I really like this proposal is not because it enables me to write less code, but because it allows me to scope a field to a property. A top source of bugs in the past has been inadequate control over direct field access and enforcing consistent property access. Refactoring into multiple types to add that desirable scope is quite often not worth it.

To that end, a field keyword makes perfect sense. I should not care or have to care what the backing field's name is. Ideally, it doesn't have one. This adds the convenience that renaming properties gets a lot easier.

Not infrequently I'm renaming constructs such as this, where Set handles INotifyPropertyChanged.PropertyChanged:

private bool someProperty;
public bool SomeProperty { get { return someProperty; } private set { Set(ref someProperty, value); } }

This kills two birds with one stone: 1) scope safety, 2) more DRY, less maintenence:

public bool SomeProperty { get; private set { Set(ref field, value); } }

[gafter]

/cc @CyrusNajmabadi

[lachbaer]

Meanwhile some time went by. I'd like to state my opionion on the questions from the inital post.

Allow both accessors to be defined simultaneously?

Yes, definitely. A nice example is the sample at the end of this comment. A semi-auto-property with an implicit field should be constructed under either or both these circumstances:

• both, getter and setter are declared, but either is get; or set; the other having a statement/block
• an initializer is declared and the property is not an auto-property

Assing expression bodied setters? and Assign block body with return?

I'd like to have that, because simply it looks nice and would totally fit into how "assign-to"-return expressions look.

But introducing to much new behaviour and especially having the compiler and reading user to differentiate between return and non-returning bodies can be confusing. Therefore I'd go with "no" on this currently.

Prohibit field keyword if not semi-auto?

No, but it must not be highlighted by the IDE in that case, because it that context it is no keyword anymore. I think it is very unlikely that somebody converts a semi-auto-property to an ordinary property and simultaneously has a 'field' named field in scope.

If property-scoped fields become availble shall that feature be available for semi-auto-properties as well?

Yes, if any possible. SAPs allow both, getter and setter, to be defined. It would make sense to make no difference versus normal properties to restrict that feature.

[jamesqo]

Taken from @quinmars at #681 (comment), this feature would allow devs to write a 1-liner to implement lazy initialization:

public T Foo => LazyInitializer.EnsureInitialized(ref field, InitializeFoo);

private T InitializeFoo() { ... }

[mattwar]

@jamesqo Except using this LazyInitializer method has a downside (unless the initializer method is static) because you'll be creating a delegate instance each time the property is accessed.

What you want to write is:

public T Foo => 
{
   if (field == null)
   {
        System.Threading.Interlocked.CompareExchange(ref field, InitializeFoo(), null);
   }

   return field;
};

And now its not really a one-liner.

[jamesqo]

@mattwar Well they said they intend to cache point-free delegates eventually. Also what if people don't care about extra allocations because the initializer is doing something like network I/O which completely dwarfs allocating a few extra objects?

[lachbaer]

public T Foo => LazyInitializer.EnsureInitialized(ref field, InitializeFoo);

However the field keyword should not be available to every property per se. It then should be decorated with a modifier, like e.g. public field T Foo ....

[yaakov-h]

@lachbaer why?

[Boomkop3]

@CyrusNajmabadi ah, you're right, that's just for initialization. It's quite obvious now that I look at it again. Thank you!

[JimF42]

Have you considered giving the class access to the fields of other properties? I have on occasion needed to have one property's set accessor update a different property's backing field without accessing the set accessor.

[jnm2]

One of the motivations of the proposal was scoping, preventing this scenario. It's currently a reason to fall back to manually declaring a field.

[colejohnson66]

[zhuangState]

Does' field 'not support text interpolation?

[WeihanLi]

should be fixed in the latest VS preview version, see
#8634 (comment)
dotnet/roslyn#75566

[KieranDevvs]

Is this language version currently planned to be released as GA along side .NET 10 or will we potentially see it earlier?

[jnm2]

I don't believe there are any changes in the works for how C#'s releases line up with .NET's releases. That means C# 14 will be released at the same time as .NET 10.

[ssegger1]

I am running some code analysis against a syntax tree containing the new field keyword using the Roslyn 4.12.0 libraries (currently the latest available). While walking the tree, the field keyword comes back as type IdentifierNameSyntax instead of the new type FieldExpressionSyntax. Using the Syntax Visualizer in VS 2022 v17.12.4, the node shows correctly as FieldExpressionSyntax.

[333fred]

You'd need to show a more complete example. At a guess, the parse options of that tree are not set to LanguageVersion.Preview, but that's just a guess.

[ssegger1]

The same thing occurs when I build and debug with the preview version of VS 2022 v17.13.0 Preview 5. I think an update to the Roslyn libraries is required, v4.12.0 was published on Dec 4, 2024, but it is the latest available.

[CyrusNajmabadi]

@ssegger1 You'd need to show a more complete example. Like a link to a repro project where you're experiencing the issue. As Fred said, it could be an issue like not setting the correct version, but we would not be able to tell without a proper repro.

[ssegger1]

Unfortunately I am not allowed to share company code.

[HaloFour]

A repro would be independent of company code. You should be able to reproduce the behavior in a completely independent and isolated project, which you can share.

[PoseidonEnergy]

Will we be able to do volatile reads of the field keyword using Volatile.Read(ref field) or something like that?

[CyrusNajmabadi]

Yes, you will.

[PoseidonEnergy]

Nice. I just tried the following and it seems to work:

public bool MyProperty => Volatile.Read(ref field);

Wonderful. This changes everything! No more manually creating volatile backing fields for each property!

[CyrusNajmabadi]

Glad you like it!

[jinsediaoying]

For a typical lazy create scene:

public MyObj Obj => field ??= new MyObj();

field will throw a nullcheck warning, because field is a not nullable type and require a initial value.
So I have to do:

[field: AllowNull]
public MyObj Obj => field ??= new MyObj();

Is there there any better way?

[PoseidonEnergy]

This works:

public MyObj Obj { get => field ??= new MyObj(); } = default!;

[jnm2]

This is an intermediate state of the feature (#8425) and the full nullability analysis implementation work is in progress: dotnet/roslyn#77127

The hope is for you not to have to use either workaround by the time the feature is released!

[jinsediaoying]

Oh thanks, then I will just wait.

[nikonthethird]

I wrote the following property in VS Code using .NET 10 Preview 3 with <LangVersion>preview</LangVersion>.

public sealed class State {
    private Int64 length;
    public ref Int64 Length => ref length;
}

I got a suggestion to convert this into an auto-property by the tooling. When I clicked on it, the code was converted to this:

public sealed class State {
    public ref Int64 Length => ref field;
}

This however displays error CS8145: Auto-implemented properties cannot return by reference.
Is this supposed to work or did the tooling suggest a conversion that does not work?

[franchyd]

Looks like a tooling issue

[jnm2]

Can you file this as a bug at https://github.com/dotnet/roslyn/issues?

[nikonthethird]

Can you file this as a bug at https://github.com/dotnet/roslyn/issues?

Sure, will do

Edit: Link to issue: dotnet/roslyn#78225

[znakeeye]

TL;DR   We need a PropertyMarshal.GetFieldRef() method.

I love this feature. Unfortunately, its use for view model properties is a bit limited. In our codebase, I could not use this feature for 70% of our properties due the limitation described below.

The docs state:
We believe the field keyword will find a lot of its use with view models because of the elegant solution it brings for the INotifyPropertyChanged pattern.

However, it is super common for view model properties to have some code when the value changes (see Prism/BindableBase which was originally developed by Microsoft). E.g.:

private object selectedItem;
public object SelectedItem
{
    get => selectedItem;
    set => SetProperty(ref selectedItem, value, OnSelectedItemChanged);
}

protected virtual void OnSelectedItemChanged()
{
}

Now, you can still convert this property to its elegant "field" equivalent. But you will face a problem!

The problem

In the constructor, you want to initialize the backing field. Not the property! For the property above, this is crucial, since you could otherwise introduce a performance hit and/or side effects in the onChanged action.

public MyViewModel(Guid id, object selectedItem)
{
     SelectedItem = selectedItem; // Uses property setter. No way to set the field directly when we have a setter!
     //
     SelectedItem = ResolveSelectedValue(id);
}

In all MVVM projects I have worked in, we have followed a strict rule to always set the backing field in the constructors. This has proven to be less error-prone than using the property setters.

Suggested improvement

In the constructor, allow setting the field directly. Something like this:

public MyViewModel(Guid id, object selectedItem)
{
     // Sets the field directly
     SelectedItem.init(selectedItem);
     
     // This could actually be useful outside the constructor!
     SelectedItem.field = selectedItem;
     
     // Just being creative ...
     fieldof(SelectedItem) = selectedItem;
     
     // Could be useful in other areas as well. Probably my favorite.
     ref SelectedItem = selectedItem;

     // Worst case, give us a helper method! Though I'm not sure how the method would pick up the property here...
     PropertyMarshal.GetFieldRef(SelectedItem) = selectedItem;
}

[CyrusNajmabadi]

TL;DR We need a PropertyMarshal.GetFieldRef() method.

I would open a separate discussion on this. Note, @RikkiGibson may already have one, with a hypothetical fieldof feature we could do at some point in the future if there's enough need.

[RikkiGibson]

#9031

[Hermholtz]

So, you're trying to eliminate a backing field only to want to access a backing field. That's becoming ugly.

[znakeeye]

Would be nice if the compiler could detect that the backing field should be Nullable<T> when leveraging the null-coalescing operator for value types:

internal class Foo
{
    [field: ThreadStatic]
    private static Guid ThreadGuid => field ??= new(); // CS0019
}

error CS0019: Operator '??=' cannot be applied to operands of type 'Guid' and 'new()'

[TwentyFourMinutes]

I would also wish this was possible, encounterd this multiple times.

[jnm2]

I would see this being addressed by #133:

private static Guid ThreadGuid { Guid? field; get => field ??= new(); }

[Limiana]

Please consider adding field keyword to event properties:

    public static event Action<IPlayerCharacter> OnTradeStart
    {
        add
        {
            if(!Initialized)
            {
                Initialize();
            }
            field += value;
        }
        remove
        {
            field -= value;
        }
    }

[binki]

It's not so much that static members are expected to be threadsafe, but the default implementation of += and -= for events are. It is true that including support for events would not be in the spirit of creating pits of success.

[HaloFour]

That would be a big difference from how explicit events work today, where += and -= against the backing field are normal Delegate.Combine and Delegate.Remove calls, without CAS.

IMO explicit events are substantially rarer to find so I don't think it's really necessary to bring field support to them at this time.

[jnm2]

It's not so much that static members are expected to be threadsafe

@binki I believe they are. We're having a discussion about it in the DotNetEvolution #runtime channel now, because I unexpectedly failed to find stronger wording than https://learn.microsoft.com/en-us/dotnet/standard/threading/managed-threading-best-practices#recommendations-for-class-libraries, but a runtime team member is confirming that historically the BCL docs have defaulted to "static members are thread safe, instance members are not unless documented otherwise."

Static-is-thread-safe-by-default is a good practice to follow, because there is no generalized recourse for synchronization of public static calls. In the general case, any library someone adds to their project could call the static member in an unsynchronized fashion.

[binki]

@jnm2

I unexpectedly failed to find stronger wording than https://learn.microsoft.com/en-us/dotnet/standard/threading/managed-threading-best-practices#recommendations-for-class-libraries, but a runtime team member is confirming that historically the BCL docs have defaulted to "static members are thread safe, instance members are not unless documented otherwise."

The behavior of implicitly implemented events is defined in the C# specification as:

When compiling a field-like event, a compiler shall automatically create storage to hold the delegate, and shall create accessors for the event that add or remove event handlers to the delegate field. The addition and removal operations are thread safe, and may (but are not required to) be done while holding the lock (§13.13) on the containing object for an instance event, or the System.Type object (§12.8.18) for a static event.

I know this is not a programming guideline, but I think this establishes the de facto behavior developers expect of events. This behavior applies to both static and instance events as clearly described in the C# specification blurb above.

It's true that custom event implementations, which would benefit most from field, don't automatically get this safety from the compiler. So any existing technique for achieving thread safety if desired or documenting lack of it would apply. A common technique would require being able to pass the field as a ref parameter to a helper, so I guess that if that works there's no actual concern here.

[jnm2]

Together with an analyzer that warns if field is used directly, that would allay my concerns.

[zms9110750]

how's this?
field(xx)

class Hi
{
public string Name{get;set;}

public int Length => field(Name).Length;
}

Allow access to fallback fields

if when you need ref

[eidylon]

I really like this.... maximum flexibility. This still saves you from having to write all the boiler-plate Get/Set code.... tho, I suppose the same thing could be achieved by

Length => this.Name.Length

tho that could get munged if the getter does any manipulation of the backing field.

[jnm2]

Option FieldNotForEncapsulation On

[binki]

If there needs to be such a syntax, I think fields.Name would be much more consistent.

[eidylon]

I dont know.... field(Name) feels consistent to me,
similar to nameof(whatever)

[CyrusNajmabadi]

field(name) can't work as that will already have new semantics in C# that we can't break (again). Consider, for example:

public Action<string, bool> Whatever
{
    get
    {
         Assert.True(field(Name));
         return field;
    }
}

[tomashruska1]

Have you considered lifting some restrictions on auto-properties not being able to return ref when using the new field keyword? is there a complication I do not see? As long as the property doesn't have a setter, this should work, no?

e.g.
public ref int Hello => ref field;
public ref int There { get { return ref field; } }

[tomashruska1]

I would say that a ref property has its uses when you need to pass a value as a reference - unlike fields they can be declared on an interface, there can be additional logic in the getter I imagine

Today you can return a ref from the property getter as long as the ref is to an explicitly declared field
private int _hello;
public ref int Hello => ref _hello;

but this is the exact reason why the field keyword was introduced in the first place, no? To simplify syntax and reduce clutter.

As for whether there even needs to be => ref field and can't be just { get; } I am happy to defer to you, although I can imagine both variants being useful in their own way

[333fred]

What Joseph is looking for is the actual use case, not a restatement of the question. We did think about ref-returning autoproperties, and determined that we didn't know of a real use case for them, as no usage of ref-returning properties that we know of today entirely encapsulates the backing field within the type itself.

[tomashruska1]

I can think of several, albeit niche ones

Ref property doesn't need to create a copy (e.g. when the property is a large struct) when accesed via getter

Or for instance I have a collection of properties in a class I want to be able to conditionally update with additional logic

What I might do is use

UpdateScope Update(Func<TThis, T> getter, Action<TThis, T> setter, T? value)

which gets fairly unwieldy

Similarly I might use dynamic expressions, which are not validated at compile time

Or I can simply use

UpdateScope Update(ref T property, T? value)

(Or I can copy the same code x times)

(Yes, all of the above have their own downsides.)

And yes, a ref auto property exposes a private field, breaking encapsulation, but so does ref property with declared backing field, which is valid c# today. If not used, it has no effect on existing code. So another argument for this feature is consistency with existing c# syntax.

[jnm2]

The goal for the field feature is to provide simplified syntax in common cases, with an understanding that the less common or niche ones will fall back to manually declaring a field. The current request is for this syntax:

-private int _xyz;
-public ref int Xyz => ref _xyz;
+public ref int Xyz { get; }

Keeping in mind that [UnscopedRef] is necessary if this property is in a struct, too- in this case, shortening from three lines to two. Given that the need so far is niche, and that the feature would not save much typing in this case, I'm not sure it's worth doing.

As an aside, I don't see a ref-returning property as "breaking encapsulation." The thing still being encapsulated is the knowledge "where is the reference stored."

On consistency I'd say two things. First, the current field and auto-property feature is self-consistent with regards to ref returns. It has consistently excluded them from its domain. I think what you're describing is more like extrapolation than like resolving an inconsistency. But second, consistency isn't an end in itself; customer success or happiness are more primary goals. Consistency perhaps is less of a motivation to invest and more of a guiding principle (among many) when creating a design.

[jnm2]

Too much consistency may equally be the death of this idea, since you might expect a ref Foo property to have a ref Foo backing field which must be set in the constructor.

[jnm2]

This feature was released as part of C# 14 today! 🎉
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-14#the-field-keyword