# C# Language Design Meeting for May 8th, 2024

## Agenda

- [`readonly` for primary constructor parameters](#readonly-for-primary-constructor-parameters)

## Quote of the Day

- "It'll work" "That doesn't sound like a ringing endorsement."

## Discussion

### `readonly` for primary constructor parameters

**Champion Issue**: https://github.com/dotnet/csharplang/issues/8105  
**Related Issue**: https://github.com/dotnet/csharplang/issues/188  
**Proposal Link**: https://github.com/dotnet/csharplang/blob/db6cac459463fdcb53e87eb6f2f41ca534e44b43/proposals/readonly-parameters.md

Today, we took a look at whether we should constrain the
[existing `readonly` parameter proposal](https://github.com/dotnet/csharplang/blob/db6cac459463fdcb53e87eb6f2f41ca534e44b43/proposals/readonly-parameters.md)
to just be for primary constructor parameters. Notably, we're not looking whether we should do `readonly` in general; we're only looking at whether we want to
do `readonly` for primary constructor parameters separately and first. The full proposal takes the view that primary constructor parameters should be treated
as parameters fully and completely, so marking one `readonly` would mean that no assignment of the parameter is possible (outside `unsafe` code), even in locations
that can modify instance `readonly` members like instance member initializers or constructor bodies. Given this, and a general lack of belief that primary
constructor parameters should be mutable in those locations, makes us wonder why we'd break `readonly` apart into multiple stages here.

We did also discuss other approaches to the problem that some users are facing here; mainly, is there an analyzer approach that can work such that users can
effectively get `readonly` by default, and then be able to opt into mutability? We think there is, and the idea is worth exploring, but it's important to note that
when we've previously added `readonly` to new locations, it's been driven by codegen needs. The ability to mark `struct` members as `readonly`, for example, allowed
the compiler to avoid `dup` instructions where it would otherwise need to make defensive data copies. The same is true for `readonly` on `ref`s. There's no real
codegen advantages to speak of here; given that we don't guarantee that primary constructor parameters are even captured as fields, there's no guarantee we could
make that `readonly` will be applied to any instance members that are generated from primary constructor parameters marked `readonly`. It may be worth exploring the
analyzer avenue further, though we do want to be very cautious about effectively shipping a language feature as an analyzer, rather than a core part of C#, especially
one that would affect a core way the language feels.

Given these sentiments, we feel comfortable rejecting the narrow version of this proposal. We are not rejecting the overall proposal; there is still plenty of debate
to be had on whether `readonly` on parameters is a general thing we want to have in C#. But we are confident that we don't want to do the narrow version where it
only applies to primary constructor parameters.

#### Conclusion

Narrow proposal is rejected.
