Champion "readonly for locals and parameters"

[gafter]

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

See also dotnet/roslyn#115

Design review

• 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

[gulshan]

Any plan for readonly types(classes and structs)?

[Thaina]

should support

readonly i = 0; // shorthand for readonly var
const j = 0; // shorthand for const var

[jnm2]

Wasn't val going to be short for readonly var?

[Thaina]

@jnm2 I just don't like the idea of adding new keyword. Especially it is already have keyword in the language that has the same meaning

readonly might be a bit longer but we already preserved it from the start. We should reuse it. And to be shorter, just let we use readonly without var

At least I have seen some suggestion to use let that would still better than val because we already have it as keyword, even for linq scope

Especially because val was not keyword. I really have my code var val = 0; and I bet there are many people have val as variable or field name in their code like me. I think val is a bad choice

[jnm2]

@Thaina Yes, I'm inclined to agree.

[HaloFour]

@Thaina

Especially because val was not keyword. I really have my code var val = 0; and I bet there are many people have val as variable or field name in their code like me. I think val is a bad choice

And you could continue to. Like var, val would be a contextual keyword, in that it only behaves like the keyword when it doesn't make sense for it to behave like anything else. So var val = 0; would remain perfectly legal.

Although I do prefer let to val, mostly because I think it looks sufficiently different.

[jnm2]

Oh yes! let was the one I liked. Thanks!

[Thaina]

@HaloFour It not breaking change I understand but it still ambiguous

BTW I still don't like let. I prefer readonly. But at least let is better than val

[benaadams]

let is a bit early basic; also was read write. Not sure how let implies readonly?

[HaloFour]

@benaadams

let is a bit early basic; also was read write. Not sure how let implies readonly?

let is also F# where it is the readonly (by default) binding of an identifier. let is also C# LINQ where it is the declaration of a readonly range variable.

Personally the latter reason is enough for me. It's already a contextual keyword, and in that existing context it creates a readonly identifier.

[benaadams]

let is also C# LINQ where it is the declaration of a readonly range variable.

Fair enough 😄

[Richiban]

@gulshan

Any plan for readonly types(classes and structs)?

Do you mean immutable types? If so, that's a completely separate proposal (I'm pretty sure it's been made before).

[soroshsabz]

ITNOA

@Richiban where I can found it?

[Richiban]

@soroshsabz

ITNOA

That's a new one!

dotnet/roslyn#7626 and https://github.com/dotnet/roslyn/issues/159 are probably what you're looking for.

[HaloFour]

Something I like about final locals in Java is that it's possible to declare one as not assigned and then have branching logic to assign it. The Java compiler uses flow analysis to ensure that for each branch that the local is assigned exactly once.

final String name;
if (entity instanceof Person) {
    Person person = (Person)person;
    name = person.getFirstName() + " " + person.getLastName();
}
else if (entity instanceof Company) {
    Company company = (Company)company;
    name = company.getFirmName();
}

This can be useful in those scenarios where you want the local to be readonly, the expression to calculate it can throw and you want the scope of the local to exist beyond a try block.

[vladd]

I would argue that shallow immutablity (readonlyness) is useful mostly for the developer, in order to protect from silly mistakes. As far as yesterday I found in my code a mistake: I was modifying a wrong local variable by mistake inside some if-branch. Readonly would have prevented this bug.

So the advantage is not efficiency but ease of reasoning about the code.

[CyrusNajmabadi]

in order to protect from silly mistakes.

Right. The issue is that we don't see this mistake happening much in the wild. As such, making a heavyweight, noisy, feature like this to prevent it is not palatable. We recommend that if this is not something you want, you write an analyzer for this purpose.

[vladd]

Well, I cannot speak for the majority of C# users, but I find myself often in a position where I would prefer having readonlyness available. It must not be necessarily noisy, a simple let would do. However, I don't know is the implementation in the compiler is going to be heavyweight.

[Hermholtz]

That let would have semantic different from let in other languages. And it does not convey the notion of being readonly/immutable. As a C# language user I'm against this.

[tats-u]

That let would have semantic different from let in other languages

"Other languages" only applies to JS/TS. Rust/Swift/F#/Ocaml use let as immutable variables.

[CyrusNajmabadi]

We're also far removed from TS/js anyways. Both of us use 'var', but to mean something very different. So alignment with them on locals is already well out the window.

[Aniobodo]

in order to protect from silly mistakes.

Right. The issue is that we don't see this mistake happening much in the wild. As such, making a heavyweight, noisy, feature like this to prevent it is not palatable. We recommend that if this is not something you want, you write an analyzer for this purpose.

That scenario is more common than you think

[HaloFour]

It must not be necessarily noisy, a simple let would do.

Which can only ever solve for one particular use case, namely inferred locals. It doesn't help with parameters, and it doesn't help for anyone who prefers to not use type inference. There are no options to make it not noisy from the language perspective, aside creating a dialect.

[vladd]

@HaloFour let int x = 42; is not too noisy as well.

[HaloFour]

@vladd

let int x = 42; is not too noisy as well.

The language team disagrees with you. It's an additional modifier which, for the folks that want this feature, would end up added to the vast majority of all declarations. That is noisy. The fact that it's 3 characters instead of 8 doesn't really change that.

[vladd]

@HaloFour If the alternative is no readonly for locals at all, I would prefer "noisy" 3 characters. Perfect is the enemy of good.

[vladd]

@HaloFour
I wonder why does language team think that extra 3 characters is an unbearable noise, whereas culture-invariant string interpolation has to be encoded in a really inelegant way string.Create(CultureInfo.InvariantCulture, $"it was {value}");
</offtopic>

[HaloFour]

If the alternative is no readonly for locals at all, I would prefer "noisy" 3 characters. Perfect is the enemy of good.

The alternative is an analyzer, so you can choose whether you want locals to be treated as readonly by default, as an analyzer is allowed to make decisions that the language won't.

[vladd]

@HaloFour Analyzer is a poor man's alternative (which is, well, better than nothing). This alternative would create a non-standard language dialect, developers will need to learn how to apply the needed analyzer, how to fight its bugs, how to cancel the readonlyness for cases where it's not intended and so on. In some organizations this would create an additional SOUP item.

[vladd]

@CyrusNajmabadi

1. Nevertheless, the languages somehow limited access to some fields in certain circumstances by adding keywords private/protected to the language. Out of pure interest, would the LDT rather not add accessibility modifiers to the language, taking the position you've just voiced into consideration?
2. You said that the whole LDT has been unanimous in uselessness of features like this one since 10 years. Nevertheless, Neal Gafter had created this issue 7 years ago, while still being a part of LDT.

[HaloFour]

Nevertheless, the languages somehow limited access to some fields in certain circumstances by adding keywords

Notably, private is the default modifier for all members. A modifier is only required to explicitly expose a member.

[CyrusNajmabadi]

Nevertheless, the languages somehow limited access to some fields in certain circumstances by adding keywords private/protected to the language.

Yes. We view fields and locals differently. Also, for fields, they are private by default.

Out of pure interest, would the LDT rather not add accessibility modifiers to the language, taking the position you've just voiced into consideration?

We would likely not add a modifier that we felt should be the default and would add a ton of noise.

You said that the whole LDT has been unanimous in uselessness of features like this one since 10 years.

I don't recall ever saying that.

[CyrusNajmabadi]

created this issue 7 years ago, while still being a part of LDT.

We still create issues for ideas for our discussions. We have discussed this enumerable times and haven't seen information that has changed our mind here. We are not opposed to ideas. But that doesn't mean we will do something about every idea. In this case, we've determined this is likely never to be done as the cons far outweigh the pros.

[Hermholtz]

this would create an additional SOUP item.

In (at least some of) these biggest tech companies pre-commit or pre-submit hooks invoke a stunning number of analyzers. They're first-class citizens and they enhance languages with features never thought of. Thanks to them the code is as perfect as it can possibly be. So if it works for FAANG, I'd say it might work for you as well.

[HaloFour]

@vladd

It doesn't create a dialect, it limits what you can do within the standard language. This is no different from StyleCop or any of the other tools routinely used by organizations to enforce code hygiene. It's infinitely cheaper than a language change and addresses all of these concerns, including the ability to flip the default, or to enforce in some situations and not others.

[333fred]

In the interest of making the language team's position on this clear, we've decided to close this issue, mark it Likely Never, lock it, and are moving the existing comments over to a discussion. It is our position at this time that readonly locals are not going to be added to the language; we do not feel that the noise from adding readonly as a local modifier, which will then need to be applied to most local variables, is worth it for the benefits that such a change would bring. We also do not believe that benefits here would be worth introducing a compiler switch or language dialect. readonly on parameters is still an open question, and we will track that specific proposal here. If we someday change our minds on readonly locals, we will create a new champion issue at that point.

[tannergooding]

But a developing "C# is soo old, it doesn't even support readonlys" attitude is a risk amongst new developers who start out learning good practices with TS and then encounter other languages.

I'm very doubtful people will say this. Even in some other popular languages (like Java or C++) that are mutable first and provide some syntax for annotating locals as readonly, it is fairly rare to see in practice in real world codebases. Additionally, as others have indicated, new language features have mostly negated the need in previously more common scenarios (typically around implicit capturing). Seeing const T in C++ for example is rare and often frowned upon or left as ambivalent in the style guides, it is very different in concept from const T* or const T& where mutations would otherwise represent a visible side effect (and for which C# does provide both ref readonly and in).

Immutable first languages are a bit of a different story. Immutable by default is often considered a "better default", but its clearly too late for C# to make such a change. Such languages then often have an explicit keyword to indicate parameters should be mutable and that is what is applied rarely, because the need to mutate in practice is generally considered rare. Being immutable first also solves many other problems, like things being deeply immutable by default so you don't end up with a.M() for readonly T a mutating or being possible to mutate in the future based on some internal implementation detail.

Such languages often have more explicit optimizations and passes to go and ensure the code is performant. Computers are ultimately imperative mutating state machines and languages that opt for immutable first and functional like designs are provide a set of tools and abstractions. Such compilers have to transform such abstractions into the low-level way computers actually work. The compiler doing the analysis to track memory, to decide whether something is last use or not, and to do the low-level transforms can be beneficial in many cases, but if its not the way the language was designed from day 1, it can equally be a hindrance instead or lead to suboptimal usage and scenarios. There are also many cases, especially in lowlevel/perf oriented code where you explicitly want and need to go against such "immutable first" or "functional first" designs, because the abstractions become too great, don't provide the right guarantees, or lead to bad code generation.

It's not a "one is clearly better than the other" scenario, it's instead a "one is better in some scenarios and can be a better default for typical user code, if designed into the language from the ground up".

[njeisecke]

Seeing const T in C++ for example is rare and often frowned upon or left as ambivalent in the style guides

My impression is that most modern C++ code is using const T (or actually const auto) very frequently. And this is absolutely no problem, use it in new code, use it when modernizing code.

Actually I would suggest renaming "C++" to "const auto".

[Thaina]

This discussion was moved from the issue, but even then it was 1000+ comment. You can't denied it has a strong interest to support this feature in C#. To have shrug it off so easily by stating that it was "position" of the team is totally disturbing

It was also contradiction to say that this feature will not be utilized, and saying that it would have too much noise in the codebase. I never have feel the noise from volatile keyword while I myself never know what it was being used for

[Thaina]

On the other hand. I have been argue many times that readonly was being preserved as keyword from the start. So using it in local variable should be just supported by default with no effect. People can use it or not is up to their own liking

But if I see any code from my team and see variable was marked as readonly I would be happy to know beforehand that this variable will not be changed and expect to not be changed, the owner of this code was really convey intention that it was very important to not change value of this variable no matter what you would do

[CyrusNajmabadi]

To have shrug it off so easily ... is totally disturbing

This topic was discussed by the team numerous times. The points and counterpoints were made. We decided based on all the information and arguments on what to do. Since then, nothing has changed. For example, your posts contain the same arguments that were heard and debated numerous times already.

Given no new information (in years at this point), and the circular nature of people making the same arguments and receiving the same responses, it was sensible to just state the team position firmly and convert this to a discussion.

[TahirAhmadov]

This got me thinking, are there arguments for or against (in an ideal world of writing C# from scratch with today's knowledge) making fields readonly by default? My thinking is, there is a benefit to consistency, if we agree that locals and params are readonly by default (in an ideal world), kind of makes sense for fields to be the same. I'm sure there are reasons why that line of thinking is wrong and I'd like to hear them.

[vladd]

@HaloFour s/people/corporation with a lot of resources/?
I don't think that two programmers and a cat are able to create and maintain a new direction of C# development.

[HaloFour]

@vladd

Don't underestimate that cat.

[alrz]

Funny thing, I've heard a lof of veteran .NET developers saying they love .NET because Microsoft provides a solution for "everything",

I would love if the dnf would create a dotnet-contrib org for high quality community libs that are developed explicitly out of microsoft. I think newtonsoft.json would be one of the first to graduate.

[KennethHoff]

I think newtonsoft.json would be one of the first to graduate.

The developer of Newtonsoft works at Microsoft nowadays and IIRC recommends STJ, so I don't see this happening

[alrz]

That was not the point though, the library itself is not ms backed. But it is joined to dotnet foundation, not sure if we have a catalog for such projects but my suggestion was about the repository.

[sirinath]

There are my arguments for:

• 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.

• 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.

readonly locals can easily be val like in Scala or let.

Also for immutability by default will not fly as I have seen many people suggest else where. The current language is mutability by default. This should stay as it is. Again this works well for Java, so I don't see a problem or argument why this will be problem for C#.

Also immutable at the CLR level will open possibilities for its use and optimisation in languages other than C# too.

NB: Moved from #8478

[HaloFour]

Either way, I don't think the language design decisions of Java from 27 years ago really matter to the language design decisions made by the C# team today. They've certainly factored the capabilities of Java when designing C# and didn't find it a necessary addition. While I don't have anything that definitively states this, the fact that final locals/parameters were added at the same time as anonymous classes and not before seemingly indicates that the explicit declaration of immutability for the sake of capturing and shared state was the primary motivation. That remains the only case where you are required to declare a local as final. The move away from this with "effectively final" and lambda capturing seems to indicate a change of mind by that design team. And sure, you can sprinkle final everywhere in Java, that's your prerogative, and there are some projects that do this, but that only illustrates the problem that the C# team wishes to avoid. Even in the Java world it's more common these days to apply these kinds of rules through style guides which can be enforced by the IDE and build system.

[CyrusNajmabadi]

The fact that this works very well in Java

You may think it works well. That doesn't mean we think it works well. Note, we agree empirically that you see this approach in other languages. That is not what is being debated. What we disagree on is whether such a feature would be a good thing for our language.

The argument has never been that we can't do this. We obviously know we can. The argument is over if that's a good thing or not. Pointing to other languages where it exists doesn't change that as those other languages are not c#. Furthermore, many of the problems and concerns we have around what this would do for our language we do see when this sort of approach is taken elsewhere.

[CyrusNajmabadi]

the place I felt very need for immutable variable

We do not have immutable variables, and will likely never get them. Furthermore, it is precisely within methods that we see a greatly diminished need for immutability. Methods are a good location where normal, bog standard, von neuman work happens. You process data, you build info into buffers and temp objects. You manipulate and massage. And then, at the end, yes you often make an immutable value to return the result.

We think this is totally reasonable and we haven't seen anything (esp data) indicating any sort of problem here that needs flipping the default or adding a nuisance modifier.

You feel differently. We get that. But that's life.

[CyrusNajmabadi]

The move away from this with "effectively final" and lambda capturing seems to indicate a change of mind by that design team. And sure, you can sprinkle final everywhere in Java, that's your prerogative, and there are some projects that do this, but that only illustrates the problem that the C# team wishes to avoid. Even in the Java world it's more common these days to apply these kinds of rules through style guides which can be enforced by the IDE and build system.

Indeed. A lot of people here seem to think that just because another language has something that it is both good and doesn't instead serve as something that itself could be a mistake or something to look to to avoid problems with in our language.

[CyrusNajmabadi]

This is really from my experience, the place I felt very need for immutable variable is function that have long chain of reactive operation

So write an analyzer that blocks you from assigning into that variable in that case.

The ide already tells you when you've reassigned the variable. You can take that code and repackage it into an analyzer that will just block you in that case. You don't need a language feature here.