C# Language Design Meeting for April 2nd, 2025

Agenda

• User Defined Compound Assignment Operators
  • Should readonly modifier be allowed in structures?
  • Should shadowing be allowed
  • Should we have any consistency enforcement between declared += and + operators?
• Readonly setters
  • Expansions

Quote(s) of the Day

var csharp14 = [improvement1, improvement2, improvement3]

• There isn't a deep need to rescue people here.

Discussion

User Defined Compound Assignment Operators

Champion issue: https://github.com/dotnet/csharplang/issues/9101
Specification: User Defined Compound Assignment Operators.
Discussion: https://github.com/dotnet/csharplang/discussions/9100

Should readonly modifier be allowed in structures?

Question: https://github.com/dotnet/csharplang/blob/f0c692748ee5067fd59ed0ece46d79a408fe50d0/proposals/user-defined-compound-assignment.md#should-readonly-modifier-be-allowed-in-structures

Our first topic today is about whether we should allow a readonly modifier for compound assignments. The current specification requires the target of the operator to be a variable. In some cases, these could be beneficial - such as in wrapper classes that expose a subset of a type's surface. Also, there was concern about readonly structs needing to have all members readonly.

Full support would require additional design work.

Conclusion

We will allow readonly modifiers, but we will not relax the target requirements at this time.

Should shadowing be allowed

Question: https://github.com/dotnet/csharplang/blob/f0c692748ee5067fd59ed0ece46d79a408fe50d0/proposals/user-defined-compound-assignment.md#should-shadowing-be-allowed

We discussed that the implementation of user-defined operators is via methods and that behavior that did not match methods may seem strange.

Conclusion

Shadowing will be allowed with the same rules as methods.

Should we have any consistency enforcement between declared += and + operators?

Question: https://github.com/dotnet/csharplang/blob/f0c692748ee5067fd59ed0ece46d79a408fe50d0/proposals/user-defined-compound-assignment.md#should-we-have-any-consistency-enforcement-between-declared--and--operators

This was a follow-up on concerns raised in LDM-2025-02-12. Authors may accidentally push their users into odd scenarios where a += may work, but + won't (or vice versa) because one form declares extra operators than the other.

There were concerns about enforcing such a rule.

Conclusion

Checks will not be done on consistency between different forms of operators.

Readonly setters

Champion issue: https://github.com/dotnet/csharplang/issues/9174
Specification: Readonly setter calls on non-variables
Discussion: https://github.com/dotnet/csharplang/discussions/2068

Expansions

Question: https://github.com/dotnet/csharplang/blob/e34ecf622058b53f0fb37705baa8597ea045d378/proposals/readonly-setter-calls-on-non-variables.md#expansions

There are cases where it is appropriate to error if a non-readonly setter is called, that may be reasonable when a readonly setter is called. We explored two of those cases that currently error with CS1918 Member of property ... cannot be assigned with an object initializer because it is of a value type. Should we include allowing readonly setters in these cases as part of the broader feature.

A change would be needed to the C# spec on object initializers (§12.8.16.3), which will be added to this proposal.

It was noted that expansions could be split off and done after the rest of the work in this proposal.

Conclusion

We will include expansions in the Readonly Setter calls on non-variables proposal