[Proposal]: Raise compiler warning when the value of a parameter is changed.

[dlemstra]

Introduction

This proposal suggests adding a new compiler warning that identifies when a parameter's value is changed within a method body. Modifying parameter values is a practice that can lead to code that is harder to understand, maintain, and debug. When a parameter's value is changed within a method, it creates several problems:

• Reduced readability: Readers of the code must keep track of the changing state of the parameter throughout the method.
• Difficult debugging: Tracking down issues becomes more complex when parameter values change during execution.
• Violated expectations: Parameters are conceptually inputs to a method, not temporary variables.
• Reduced maintainability: Code becomes harder to refactor when parameters serve multiple purposes.

Proposed Solution

The proposal is to add a compiler warning when a parameter's value is directly modified. This would help developers identify and avoid this practice in favor of more maintainable alternatives.

This warning would be particularly valuable for code using primary constructors, which were introduced in C# 12. Primary constructors expose their parameters to the entire class scope, creating a significant risk for unintended modifications. It would help prevent subtle bugs that occur when primary constructor parameters are modified after class initialization. Since these parameters often represent dependencies or configuration that should remain constant throughout the object's lifecycle, detecting mutations would improve code reliability and maintainability.

Why a warning

A key advantage of implementing this as a compiler warning rather than a hard error is the flexibility it provides to developers. They can control how strictly they want to enforce this guideline:

• Treat as Error: Teams can configure the warning to be treated as an error using compiler options (e.g., /warnaserror:CSXXXX) or in project files, enforcing immutable parameters as a strict coding standard.
• Disable Selectively: The warning can be disabled for specific code sections where parameter modification is intentional using #pragma warning disable CSXXXX.

[HaloFour]

You can add a warning for parameter reassignments through an analyzer.

[jaredpar]

Yes analyzer is the appropriate avenue here. There is virtually no chance that we'd make this change in the language itself.

[dlemstra]

Was this not the correct spot/repository to request this? I posted it here because I thought it would be a good idea that during compilation a warning that is enabled by default would be raised. I can also understand that a change like might be only introduced in a new language version because of the possible impact.

[HaloFour]

Roslyn Analyzers are tools that can be plugged into the compiler in the project settings to enforce certain rules and can issue diagnostics like warnings or errors. They would be the preferred way to layer rules like this on top of the standard language and they can be written by anyone in the community and shipped as a part of a NuGet package.

I had proposed an analyzer that would cover this use case and other reassignment scenarios as a way to be able to dial in a degree of "readonly"-ness across a project without taking a hard opinion across the board.

[jaredpar]

Was this not the correct spot/repository to request this?

It's fine to post it here, it's just very little chance we'd ever take this

I posted it here because I thought it would be a good idea that during compilation a warning that is enabled by default would be raised. I can also understand that a change like might be only introduced in a new language version because of the possible impact.

Warnings on existing code are a breaking change and must clear a very high bar for inclusion in the compiler. This is true even if we tie the warning to a target framework change. Cause eventually customers will change the target framework and that will trigger them being forced to deal with it.

Other factors we have to consider:

• Chance that this will fire on existing code: I would rate it extremely likely that this fires on existing code. Modifying parameters has been legal, and a common pattern, since C# 1.0. The chance of this impacting any given customer is close to 100%.
• Chance that the existing pattern represents a real error that customers need to be alerted about: I would rate this very low for this warning. Again ... it's common practice in C# to do this (love or hate it).

Modifying parameter values is a practice that can lead to code that is harder to understand, maintain, and debug.

Just don't agree with this premise overall. Yes if I were designing a language from scratch I would likely defer to readonly locals and parameters. But C# is a 20 year old language that was mutable by default. Attempting to enforce readonly by default, particularly for existing patterns, is fighting against history here.

[Rubidium37]

I see some exceptions:

• A collection parameter (like ICollection<>, IList<>, IDictionary<,> and so on) that was passed on purpose to be filled by the method.
• The parameter is forwarded to some other method that may or may not change its contents.
• The parameter is a complex object that provides instance methods that will be call by my method and such methods may or may bnot change it.
• The parameter can have an invalid value and I want to fix the value to a valid one before using it. do I need to allocate a new local variable to get rid of the warning ? Or do I need to pollute the code with warning suppressions ?

Can I avoid being warned by the compiler in such cases?
How can someone inspecting the method assume something about the parameters values if such exceptions exist?

[TahirAhmadov]

You are conflating 1) modifying an object which is referenced by a variable (like a parameter), with 2) storing a new reference into that variable. These two things are completely different.

1. can in no way be controlled at the variable declaration site - how an object allows outsiders to modify itself is only defined by the object declaration.
2. falls under "readonly variables": Champion "readonly for locals and parameters" #8479. TLDR: the language is not going to add keywords to make variables readonly (locals or parameters), and language will not do a "readonly by default" compilation switch, like for NRTs, because it's not worth it. Like mentioned by HaloFour, an analyzer is a perfectly sufficient avenue here for an organization/project to opt in to readonly-ness by default.

The parameter can have an invalid value and I want to fix the value to a valid one before using it. do I need to allocate a new local variable to get rid of the warning ? Or do I need to pollute the code with warning suppressions ?

In a hypothetical world of parameters being readonly (either by a language rule, like in a functional language, or by an analyzer), yes - if you want to set a new value to variable, you declare a new variable. This approach has its benefits and with modern optimization techniques, virtually none of the downsides (ie. no extra stack space is consumed because in optimized code, the actual memory space can be reused).

[TahirAhmadov]

#8479

[The-Futurist]

It would help to see an example or two, also consider there are ref and out parameters too so it would help to be very specific about the scenario your concerned about.

Are you referring to calling set properties on an object reference passed by value? there are already mechanisms available for enforcing immutability which is what you seem to be alluding to.

[MadsTorgersen]

I do think this proposal has merit, in that is offers a potential way out of a deadlock we have in the language: On the one hand, a lot of people express their desire to prevent mutation of parameters. On the other hand, adding syntax for this (e.g. a readonly modifier) leads to more cluttered signatures, and seems a high price to pay.

Of course, making it an outright error in C# would be a massive breaking change, and as Jared calls out above, even a warning can be problematic. But issuing a diagnostic that users can then change the severity of could provide a way for people to protect their parameters without extra syntax, and for C# to embrace the scenario without punting to analyzers.

[HaloFour]

Is there much of a line between a compiler diagnostic and one emitted by an analyzer that ships out of the box with the tooling?

I ask because I feel like the latter provides much more opportunity to explore the space and not just scratch one very specific itch. It also allows more control over policy, e.g. an explicit way to opt-in to allowing reassignment in specific cases.

[TahirAhmadov]

On the one hand, making it a compiler diagnostic does sort of "start the process" towards making C# readonly-by-default, even if it's a very very long road.
On the other hand, like HaloFour rightfully points out, what about all the other places? In his analyzer proposal, he put together and self-admitted incomplete list of like 6 different possible rules, and some caveats in that discussion dotnet/roslyn-analyzers#7422.