- "It'll work" "That doesn't sound like a ringing endorsement."
Champion Issue: #8105
Related Issue: #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
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 refs. 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.
Narrow proposal is rejected.