[Proposal]: readonly parameters

[333fred]

readonly parameters

Champion issue: #8716

Summary

We allow parameters to be marked with readonly. This disallows them from being assigned to or being passed by ref or out.

Motivation

C# users have long requested the ability to mark both locals and parameters as readonly. The design team has somewhat resisted this for two reasons:

• The view that readonly on parameters and locals would be an attractive nuisance more than a helpful addition.
• Indecision on what a succinct syntax for locals would be to minimize the nuisance part of the first objection.

However, the addition of primary constructor parameters changes that calculus, at least for parameters. A significant piece of feedback from the initial preview is that users would like to be able to ensure that primary constructor parameters are not modified. The scope of such parameters is much larger, so the danger of accidental modification is much higher. We therefore propose allowing readonly as a parameter modifier.

This proposal makes a few assumptions about readonly locals as part of it:

• A future design would allow readonly as a local modifier.
• That future design might allow a shorthand for readonly var, or may say that readonly var is not allowed, and the separate shorthand is required for a readonly type-inferred local. What that shorthand
  is (val, let, const, or some other keyword) is beyond the scope of this proposal.

These assumptions allow us to presume that to fully spell out readonlyness for a parameter or local requires a modifier, and that modifier is readonly. In places where types can be inferred, we offer a
shorthand that combines the meanings, but otherwise readonly is required.

Specification

https://github.com/dotnet/csharplang/blob/main/proposals/readonly-parameters.md

LDM Discussions

• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-27.md#readonly-modifiers-for-primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-17.md#readonly-parameters
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-26.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-31.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-05-08.md#readonly-for-primary-constructor-parameters

[HaloFour]

I always viewed this proposal as a stepping stone into a potential wider application of readonly being applied to parameters and locals. However, my thinking on that subject has changed and now I question whether readonly parameters in general would be a useful feature.

That said, being able to apply readonly to primary constructor parameters specifically I think has real potential value, and perhaps could be considered as a wider proposal to allow certain modifiers on those parameters to "promote" them to type members.

There is a lot of overlap between the two, although one could argue that the scope during which the primary constructor parameter is reassignable is different depending on whether you treat it as a parameter vs. as a field.

[julealgon]

Would it make sense to limit this to only primary constructor parameters?

I'm slightly worried this could become out of hand for "normal" methods... for example, we probably want to have all constructor parameters always enforce this, but if we enforce it for every method it will become super noisy and verbose.

Makes me wish all parameters were readonly by default from the beginning of the language, since that seems much better as a default than the other way around.

[333fred]

Would it make sense to limit this to only primary constructor parameters?

Yes, that is one of the points that the LDM has been actively debating. I don't recall that we've for certain said one way or the other, but my impression of our leaning is towards just PC parameters.

[DavidArno]

That said, being able to apply readonly to primary constructor parameters specifically I think has real potential value, and perhaps could be considered as a wider proposal to allow certain modifiers on those parameters to "promote" them to type members.

My position on this has changed hugely over the last year. A year ago, I'd be clamouring for the ability to mark PC parameters as readonly. But as an experiment, we introduced a mandatory analyzer to our code base that treats mutating a PC parameter as an error. This provided the perfect solution as we have never found a compelling use-case that would justify allowing them to mutate. Mutating PC parameters turned out to be a YAGNI feature with obvious undesirable consequences that in reality were very easily to overcome. I do not see any point in swapping that clean solution for suddenly allowing them to mutate by default and having to add readonly to stop it.

Therefore, as far as I'm concerned, the solution here is to add a warning-wave warning on parameter mutation to a future release that embeds that analyzer into the language. Job done: this issue can then be closed.

[KennethHoff]

My position on this has changed hugely over the last year. A year ago, I'd be clamouring for the ability to mark PC parameters as readonly

As someone who has here then; can confirm - he was! 😂

I agree wholeheartedly though. I was less hesitant to try mutable PCs than David were, but even so I still wanted readonly back then. I'm much less convinced nowadays that these 9 additional characters would improve the DX

[julealgon]

That said, being able to apply readonly to primary constructor parameters specifically I think has real potential value, and perhaps could be considered as a wider proposal to allow certain modifiers on those parameters to "promote" them to type members.

My position on this has changed hugely over the last year. A year ago, I'd be clamouring for the ability to mark PC parameters as readonly. But as an experiment, we introduced a mandatory analyzer to our code base that treats mutating a PC parameter as an error. This provided the perfect solution as we have never found a compelling use-case that would justify allowing them to mutate. Mutating PC parameters turned out to be a YAGNI feature with obvious undesirable consequences that in reality were very easily to overcome. I do not see any point in swapping that clean solution for suddenly allowing them to mutate by default and having to add readonly to stop it.

Therefore, as far as I'm concerned, the solution here is to add a warning-wave warning on parameter mutation to a future release that embeds that analyzer into the language. Job done: this issue can then be closed.

@DavidArno I see where you are coming from here, but at the same time I think doing it your way creates a less consistent language, which is something I'm not super fond of.

If you make it so that the "default" for PC arguments is for them to be readonly by default via an analyzer, you are effectively warping normal conventions which say that arguments are mutable by default everywhere else arguments are used.

To me, the explicit readonly requirement results in a more consistent behavior, even if it is, yes, more verbose, and even if we only allow it on PC arguments (yes, this also creates an inconsistency in and of itself, but a less harsh one that completely flipping the behavior of something that has existed since the language was created.

Would I have preferred all arguments to be readonly by default? Absolutely. But that boat has sailed now... unless the team was willing to take a bit risk here and introduce a super breaking change over multiple language versions with deprecation warnings and all that stuff. In a sense, this is a similar conundrum than the (now deemed a bad decision) decision of having classes be nullable by default and the later clash with the introduction of nullable reference types: NRT will never be able to be enforced in a stronger manner without completely breaking a ton of code, so it can only live as a "lesser" analyzer/static analysis thing.

Similarly, I'd have preferred 'sealed' to be the default, and 'virtual' to be the opt-in modifier for classes, but it was similarly decided way too early on that the opposite was to be the case, and now we are stuck with a "bad default". Could we introduce an analyzer to detect inheritance and force people to use something like an attribute to indicate "virtual" and abandon the 'sealed' modifier?

All that to say that each time the team makes a decision that creates a special case, that thing stays in the ecosystem indefinitely and this compounds over time to create an overall inconsistent and confusing language. Swapping the behavior of mutability for one particular case (PC arguments) even if through a built-in analyzer, will add to that inconsistency/confusion.

[CyrusNajmabadi]

For instance, introducing it as an opt-in feature via project settings (similar to nullable reference types) could provide a balanced approach:

This we are very unlikely to do. We only did this for nullable reference types as they were trying to address what we consider a trillion dollar mistake. It was that valuable that it warranted the split in the language controlled by a project flag.

Read-only PC parameters isn't there. Our first and second parties using these features just aren't running into any issues. So bifurcating the language again for such a non-issue is not something we'd do.

This is doubly true as this flag would just enable analyzers. But you don't need a flag for that today. You can just write an analyzer that already flags mutation of PC parameters. And it will work without any language or tooling upgrades. It will run and block things for all your users using PC parameters going back to the first version of the compiler where they were added.

[julealgon]

@CyrusNajmabadi

We are not "extremely unlikely to ever implement this"

This is a championed issue by an ldm member.

Well Cyrus you say that but there are very strong indicators in all these conversations that an analyzer is the way to go and all that.

Fwiw, we've switched to primary constructors for lots of the Roslyn ide code. And nearly every pr of mine moves some new type over. So far we haven't missed read-only parameters, and no bugs or issues have come up from this.

So my personal feeling is that the fear and concerns here aren't that relevant in practice.

I can definitely see that being the case, but then again... doesn't that also apply to standard readonly fields? If readonly was suddenly removed (as a keyword/feature), I could also see people doing "just fine" with no bugs because it is so unusual that field modification results in bugs anyways...

But we still have readonly fields as a default thing.

Maybe if the .NET team had the same mentality as it does today, readonly would not have been a feature in the first place (even with "mutable" being the default) because of what you just said: the chance that a readonly marker actually prevents a bug is extremely low.

[CyrusNajmabadi]

Well Cyrus you say that but there are very strong indicators in all these conversations that an analyzer is the way to go and all that.

I don't know what i could possibly say to convince you then. This is a championed issue that hte LDM is interested in. If that's not sufficient to indicate that it's not "extremely unlikely to ever implement this", then i don't know what would be.

doesn't that also apply to standard readonly fields?

readonly fields are literally from v1 of the language. They predate analyzers by like 15 years. We dont' have a time machine to go back and redo the past. We can only determine what we should do in the present and speculate on what we might do in the future.

Maybe if the .NET team had the same mentality as it does today, readonly would not have been a feature in the first place

Maybe. Who can say. We don't get to wipe the slate clean. We live with the decisions of the past and make the best decisions we can given that, and what we've learned since then.

[julealgon]

@CyrusNajmabadi

I don't know what i could possibly say to convince you then. This is a championed issue that hte LDM is interested in. If that's not sufficient to indicate that it's not "extremely unlikely to ever implement this", then i don't know what would be.

Maybe I should clarify myself then. It's not that I don't think something will be done at all, I'm saying that it seems unlikely that this will be implemented as a readonly keyword/modifier on the argument. From the conversations, it looks like having a native analyzer is much more likely.

readonly fields are literally from v1 of the language. They predate analyzers by like 15 years. We dont' have a time machine to go back and redo the past. We can only determine what we should do in the present and speculate on what we might do in the future.

Of course... but you do want to try to be consistent when possible.

Maybe. Who can say. We don't get to wipe the slate clean. We live with the decisions of the past and make the best decisions we can given that, and what we've learned since then.

Again, sure... although I do think the team should start to seriously think about ways/mechanisms to introduce breaking changes to the language. @MadsTorgersen has mentioned this numerous times in various talks, it's not even a "new" idea at this point.

The field keyword might be a small, initial experiment on that front, but I hope a larger system will eventually be put into place to actually deprecate things and do more significant breaking changes to the language.

If C# keeps going for several more years without ever introducing breaking changes, it will become like the mess that C++ is currently, or the team will have to opt into creating a new language from scratch, which is also super damaging in and of itself as it completely splits the community.

[CyrusNajmabadi]

it looks like having a native analyzer is much more likely.

I don't see any indications from teh LDM stating that.

What i'm stating is that currently, in the absence of a language feature, analyzers can serve as a good guardrail if you are concerned with this issue.

Of course... but you do want to try to be consistent when possible.

Only if the gains outweigh the losses.

If C# keeps going for several more years without ever introducing breaking changes,

We're doing breaking changes in V13 with field. We've done breaking changes in the past. Virtually every compiler release has some breaking changes.

But we do them judiciously, when there is huge value and the impact to the ecosystem is valuable and likely not to screw over tons of people doing the right hting. Breaking changes is not a blank check. It's a policy and mechanism to ensure that in the rare cases where we do want to break, we have a system for doing so and we can do it properly.

[DavidArno]

@julealgon,

I get what you are saying. But if you look through many discussions here where people say "can we have x in the language", a very common response from members of the language team is "use an analyzer/generator to achieve that". And if you suggest that analyzers and generators ought to be for domain-specific features, not language dialects, you tend to get downvoted, suggesting there is a view that they are not just for that.

The team positively encourage that less consistent language approach, therefore. But you make a good point: they are unlikely to add this to a warning wave as they do not want to create those inconsistencies themselves. That's for others to do. And this is intentional: they create generic solutions and then encourage others to customise and regulate those features according to their specific needs.

Could we introduce an analyzer to detect inheritance and force people to use something like an attribute to indicate "virtual" and abandon the 'sealed' modifier?

You really don't want to do that. Sealed classes are more performant. An analyzer that errors on a non-sealed class or record unless annotated with a [SupportsInheritance] attribute ought to definitely be on any company's mandatory analyzer list. Luckily, PC parameters do not suffer a performance hit so can be handled with an analyzer.

[CyrusNajmabadi]

The team positively encourage that less consistent language approach,

The approach is consistent. The language means the same thing everywhere, but different trans can choose which parts of the language to allow. Disallowing a part of the language doesn't make the language less consistent.

[CyrusNajmabadi]

Would I have preferred all arguments to be readonly by default? Absolutely. But that boat has sailed now... unless the team was willing to take a bit risk here and introduce a super breaking change over multiple language versions with deprecation warnings and all that stuff. In a sense, this is a similar conundrum than the (now deemed a bad decision) decision of having classes be nullable by default and the later clash with the introduction of nullable reference types: NRT will never be able to be enforced in a stronger manner without completely breaking a ton of code, so it can only live as a "lesser" analyzer/static analysis thing.

Right. And we have looked at this and decided: no, we are not willing to take that risk.

With nrt even the data there just barely was sufficient. But at least there was sufficient evidence about the bugs will null and the costs of it. That could then motivate a multi year effort across the entire ecosystem.

There legitimately is nothing like that for read-only. We do not have anything close to the number of bugs or clarity issue with mutable locals and parameters.

Instead, what we have are a set of people that just have a preference. Their mental model is to never/rarely want to mutate a local, and they want the language to cater to that by default, trapping the occasional time they accidentally violate that personal preference.

Asking for the same effort to be put in here to appease that preference is not going to happen. As David has pointed out, our view is that this is what analyzers are for. Have the language support the broad needs of all users, but use analyzers to restrict certain coding patterns you don't like in your own codebase.

[sirinath]

• The view that readonly on parameters and locals would be an attractive nuisance more than a helpful addition.
• Indecision on what a succinct syntax for locals would be to minimize the nuisance part of the first objection.

How is this possible? This is without any empirical evidence. The fact that this works very well in Java, this line of argument disproved by as it is contradictory to the real world uses.

[sirinath]

Also for immutability by default will not fly as I have seen many people suggest else where.

[333fred]

Please keep discussion of readonly locals out of this issue. You can continue discussing that topic in #8479.

[Thaina]

since readon;y is already strong keyword from the start of C# there are no reason to not allow readonly to support as default

let might be allowed and succeed readonly in the future, but that should not be any problem and should not change the usage of readonly even it was redundant

[TahirAhmadov]

To be honest, at this point I think we shouldn't do it even for PC parameters. In cases where it's typically needed, like a class with multiple dependencies on other interfaces, it would create noise just like it would have for locals. And non-PC parameters, it falls under the rubric of general readonly for locals and parameters, which has been ruled out.

At this point, the best solution is (are) analyzer(s) to allow individual projects opt in to "readonly"-ness by default.

[julealgon]

At this point, the best solution is (are) analyzer(s) to allow individual projects opt in to "readonly"-ness by default.

Having an analyzer that triggers an error/warning for something that is already triggered by a dedicated keyword in the language (even if said keyword cannot be used in that particular case) would feel like a hacky solution to me.

I can understand an analyzer for something that is not otherwise captured in the language... but readonly already exists and already provides the same capability that such analyzer would provide.

[TahirAhmadov]

Having an analyzer that triggers an error/warning for something that is already triggered by a dedicated keyword in the language (even if said keyword cannot be used in that particular case)

That goes back to the general conversation in #8479, and it was decided once and for all - readonly is not being introduced to locals, despite being available for fields. The same reasoning applies here - just because readonly is available for fields, it doesn't mean it has to be available for parameters, even PC parameters, as well.
For the IMO very few cases where PC parameters need to be mutable, they can be decorated with [Mut] attribute and the analyzer uses that.

On a tangent, I think we should use the word "write" (writable) for the opposite of "readonly", to avoid confusion with deep mutability. Perhaps said analyzer should use use [Writable] or [CanWrite]? Minor naming pedantry, but still. It would help to disambiguate writability from mutability, which is valuable given how many times people confused the two.

[KalleOlaviNiemitalo]

Would s.N() in the following be an error, because it calls a non-readonly method on a readonly parameter? A similar call in void M(ref readonly S s) or void M(in S s) is not an error and instead makes a copy.

class C {
    void M(readonly S s) {
        s.N();
    }
}

struct S {
    public void N() {}
}

If s.N() would indeed be an error there, then would ((S)s).N() likewise be an error, or would that make a copy?

[CyrusNajmabadi]

It would not be an error. Just as it's not an error to call a non read-only method on a read-only field

[EnCey]

Personally, I saw some use in readonly locals but not parameters – I strongly agree with the "attractive nuisance" mindset. The "correct" way would be to use it almost everywhere, which is a terrible idea, so when would you ever use it at all?

I want to bring this idea to the forefront, which aligns with my view:

1. introduce an NRT-like flag to opt-into the new behavior, which is:
2. all parameters everywhere are readonly by default
3. use var int i to make a parameter mutable, in the few cases that is needed – which also aligns more nicely with existing ref and out, which change a parameter so that assigning to it is significant in some way.

In my opinion, the root cause of the problem is the primary constructor design and this is just a bandaid. Making the ctor params accessible everywhere in a class is the actual problem – but that ship has sailed.
With that in mind, I would even prefer if readonly were only usable on primary constructor parameters, which behave differently from other method parameters already and where the modifier actually contributes something more meaningful.

[julealgon]

...and any further dialects must have similar weight behind them. This isn't close to meeting the bar.

I hope you'll change your minds eventually.

[333fred]

I hope you'll change your minds eventually.

I do not think that's likely unless you can show billions of dollars in real-world damages.

[EnCey]

Nullable is an issue that has, across the entire computing industry, caused likely multiple billions of dollars in damage. That is what made it worth a language dialect, and any further dialects must have similar weight behind them. This isn't close to meeting the bar.

I agree, actually. To me that means my personal preference – making all parms readonly by default – isn't doable, so next best option (for me) is to only allow this feature on primary constructors.

I know analyzers are something that the community is supposed to provide for themselves, but if you do decide to ship the attractive nuisance version of the feature (leaving a loaded gun laying on the table for people to shoot themselves in the foot with it), then I would appreciate if you shipped an analyzer with it that can be optionally turned on to disallow readonly on anything but primary constructor parameters.

[jnm2]

I'm curious to know how much actual damage is caused by lack of readonly on primary parameters. I understand the theory being presented, but for a couple of reasons, I'm curious if that really ties out to real issues in the way that has been anticipated.

[julealgon]

@jnm2 I would expect it to be more about encouraging immutable design by default and not about any specific issues, although the thing that immediately comes to my mind that hugely benefits from immutability is multi-threading scenarios since immutable classes are naturally thread-safe.

I would also assume that optimizing for speed is easier when using immutable types (be it build-time compiler optimizations or JIT).

It obviously doesn't have the same negative impact that nullability has though, I don't think anyone would argue against that.

Having said that, I do spot a lot of bugs during code reviews that are directly related to unnecessary mutability or state sharing in code. If the language in general was "less open" in that front I think those bugs would be mitigated. I don't have any specific examples at hand though.