[field-keyword] What setup is possible for ReadOnlyCollection<T> (publ. get) but which would need to be write-able from inside of the Type with this property (-> List<T>) ?

[DevTKSS]

Type of issue

Other (describe below)

Description

Reading the Docs I am missing one sample for a relatively common usecase I have had multiple times in Apps so far.

We would have for example this (before C# 14) Definition in our code:

public abstract record BaseNotificationAggregator
{
    public int Id { get; set; }

    private readonly List<BaseNotification> _Notifications = new();

    public IReadOnlyCollection<BaseNotification> Notifications => _Notifications.AsReadOnly();

    public void AddNotification(BaseNotification baseNotification)
    {
        _Notifications.Add(baseNotification);
    }

    public void RemoveNotification(BaseNotification baseNotification)
    {
        _Notifications.Remove(baseNotification);
    }

    public void ClearNotification()
    {
        _Notifications.Clear();
    }
}

where you can find our BaseNotificationAggregator

• public getter, but not modify-able => IReadOnlyCollection<T> or maybe could also be IReadOnlyList<T> if this would be a game changer
• relying on a private access-able and readonly List<T> backing field
• Methods can do their CRUD Operations on the contained Items

I would not really see a way (except from we suddenly can use >2 Accessors in a Property?) to tell the compiler that, while I want to show the Property as readonly, the Methods from inside of the Type Definition should be able to access it as Type xy, e.g. here its a regular list enabling it do its thing.
Attempting to do something on a Property that returns always a ReadOnlyList or Collection is obviously not making sense, but while general readonly Properties are told about in the linked docs, there is nothing I found about this encapsulated setup.

Page URL

https://learn.microsoft.com/de-de/dotnet/csharp/language-reference/proposals/csharp-14.0/field-keyword

Content source URL

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

[333fred]

I do not see a way to use field here, so I don't know what sample we'd be able to write on it.

[DevTKSS]

@333fred True — there is no way to use field for this pattern, now that I understand the design constraint.

Just to illustrate what I meant by “a sample,”:

here is the classic pre–C#14 pattern that a reader might consider updating:

private readonly List<Item> _items = new();

public IReadOnlyCollection<Item> Items => _items.AsReadOnly();

A reader new to the field keyword might expect that this pattern could be expressed like this:

public IReadOnlyCollection<Item> Items 
{
    get => field.AsReadOnly(); // <-- ❌ error: `IReadOnlyList<Item>` doesn't implement such method. - field has the same type as the property
    private init => field = new List<Item>();
}

But this cannot work because:

• the backing field must always be the same type as the property,
• so in this case field would be IReadOnlyCollection<Item>,
• making field.AsReadOnly() or mutation impossible.

In my opinion, visual examples like this help readers spot the limitation immediately, much more effectively than text alone.
That’s why a short note — together with a minimal non-working example — could make the design intent clearer for readers encountering this feature for the first time.

Since this clarification could help prevent misunderstandings, I’d be happy to prepare a small PR if you’d like to consider adding it.

[julealgon]

You can't have the backing field be a different type from the autoproperty, so using field here without the explicit backing field is just not possible.

[jnm2]

One of the central tenets of the field keyword feature is protection of the backing field from access by the class. You use field when the class should have no special access to the backing storage and must only interact through the property directly. However, in your use case, you want the class to have direct access to the backing storage. The vehicle for that scenario is to declare a field so that the class has something to access directly.

[DevTKSS]

@jnm2 Thanks — your explanation clarified the intent behind when we still need an explicit backing field instead of using field.

When reading the Motivation section, I initially interpreted the final paragraph:

… it also leaks the backing field into the rest of the type's scope, when it is often desirable to only have it be available to the bodies of the accessors.

as applying only to the scenarios directly above it (lazy initialization, validation, INotifyPropertyChanged, etc.). Because of that, I assumed that a pattern like a read-only property backed by a private List<T> might also be a candidate for the field keyword.

Your explanation made it clear that this is not the case:
field is specifically not intended for situations where the containing type must mutate the backing storage directly. In those cases, declaring an explicit field is the correct and intended approach.

I only found the defining line after re-reading the Nullability of the backing field section:

The backing field has the same type as the property. However, its nullable annotation may differ …

It technically answers the question, but appears much later in the document and is easy to miss when skimming.

A small clarification near the Motivation section could help avoid that misunderstanding. For example:

Note

Type restriction for the backing field

The backing field always has the same type as the property (nullable annotation may differ).
Therefore, the field keyword is not intended for scenarios where the containing type needs direct access to a different backing type (e.g., an IReadOnlyList<T> property backed by a mutable List<T>).
In such cases, an explicit field remains required.

Since this clarification could help prevent misunderstandings for readers new to the feature, I’d be happy to prepare a small PR if you’d like to consider adding it.

[jnm2]

Thanks so much for thinking this through and being willing to improve the docs!
@BillWagner I converted this issue to a discussion in error. Pinging you so that this offer of help from @DevTKSS doesn't get lost.