Back to Csharplang

C# Language Design Meeting for March 19th, 2025

meetings/2025/LDM-2025-03-19.md

latest1.9 KB
Original Source

C# Language Design Meeting for March 19th, 2025

Agenda

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 structs 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".