# C# Language Design Meeting for March 19th, 2025

## Agenda

- [Readonly setters on non-variables](#readonly-setters-on-non-variables)

## Quote of the Day

- "Sorry for the shorter meeting today"

## Discussion

### Readonly setters on non-variables

Champion issue: https://github.com/dotnet/csharplang/issues/9174  
Specification: https://github.com/dotnet/csharplang/blob/d139d200cfe8ffe45536cdcc8b17ee7f25b5757b/proposals/readonly-setter-calls-on-non-variables.md

Today, we looked at a proposal to lift an error scenario around `readonly`. One interesting thing with this is that we're already in an
inconsistent state; we permit `readonly` setters to be called on the result of a `ref`-returning method, for example. This is likely an
unintended "bug" in the implementation of `ref`-readonly methods, but at initial glance we could just make that the explicitly-allowed
behavior and standardize on that.

There was some discussion on named indexers; this is one of the primary use cases given to enable this language feature, but is that
motivation enough for this language feature? Or should we just do named indexers directly? However, as we previously noted, we want the
compiler to get to a consistent state; there are a few other motivating scenarios that we can discuss extending this feature to as well
in future design sessions.

We also brought up some concerns that this could potentially enable new dropped value scenarios, where the struct is creating a new
reference type under the hood and then being dropped. However, there's nothing unique to `struct`s here; the same type of issue as might
happen when a user uses an expression-bodied property of `{ get; } = new();` instead.

Given all of this, we think that we're fine with this proposal to move forward. We'll put it in "Any Time" for now, and revisit potential
extensions to it at a later date.

#### Conclusion

Proposal is accepted, put into "Any Time".
