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.

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

[foxesknow]

it creates effectively 2 coding styles for the same thing in the language, which is not good.

I don't think this particularly bothers the language designers as there's plenty of examples in the language. See expression-bodied members, for example.

[HaloFour]

I don't think this particularly bothers the language designers as there's plenty of examples in the language.

Where there is value in doing so, such as in making a common case less verbose and more consistent with other language constructs it may be considered to be worth it.

See expression-bodied members, for example.

Expression-bodied members were added to make single expression members match the existing syntax of lambdas. It reduces ceremony in that common case. That's in stark contrast to readonly which would increase ceremony in the majority of cases, requiring a lot of extra work to get the safety of the guardrails that it is intended to provide.

[AartBluestoke]

@Hermholtz

I'm already halfway of writing a PoC of the analyzer. Well, LLM has done everything, I'm just copying and pasting :-)

Did this ever amount to something releasable?

[Hermholtz]

Nah, my duties changed, now I'm in the C++ world, not using MS tools.

In a bare VS with some extensions (CodeMaid and Roslynator, no Resharper nor Rider) something underlines the names if they're mutated in scope, maybe that's sufficient to begin with. If not, a decent LLM will happily write a Roslyn analyzer for you.

[jnm2]

something underlines the names if they're mutated in scope

@CyrusNajmabadi put this into Roslyn itself at an early point in the discussion on this topic.

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

[sirinath]

Another thing is perhaps readonly locals and parameters can perhaps might be possible to be used to relax the constant requirement in pattern matching making pattern matching more flexible.

[jukkahyv]

Can you summarize, what's the drawback of making "readonly by default" a project setting, same as nullable? Too much confusion?

[HaloFour]

The language team is loathe to create language dialects and don't feel that readonly is worth it. The same behavior could be provided through analyzers which allow the developer to opt-in and tune the strictness external to the language itself.

[CyrusNajmabadi]

same as nullable

NRT was eventually justified due the enormous, measurable, cost that null reference exceptions were having on the ecosystem. They were a primary source of bugs, and we're causing significant costs everywhere. This alone justified the major step of introducing language dialects, with project settings to control things.

The situation is not comparable here as nothing indicates that the set of issues unresolved without this feature are in any way comparable. Wrt bugs it's likely 3-4 orders of magnitude difference. As such, the same motivations that drove us to solve nullable in this fashion do not apply here.

[Richiban]

Since this issue has been closed as 'Likely never', is the team open to splitting a LINQ-matching let [Type] variable = ... proposal into its own discussion?

I ask because I too am of the opinion that readonly parameters are going to be just too noisy; the ability to make a parameter readonly (and therefore likely IDE recommendation) is going to be the case 99% of the time. Since we can't make readonly the default in an existing language I'm no longer interested in readonly parameters.

However, "readonly" locals are still a worthwhile addition to the language and they have the advantage of 0% extra noise in the majority of cases. var x = ... becomes let x = ... and there's not a single extra character. Only explicitly-typed variable declarations get longer: string y = ... becomes let string y = ... etc.

The IDE feature released a few years ago, where mutated variables can be highlighted in the editor, is very useful for readability in the IDE but, perhaps ironically, a great deal of code is read not in the IDE but in a diff or PR where only basic syntax highlighting is normally available.

[333fred]

No. The door is not open to readonly locals, period.

[crfrolik]

It's unfortunate. If we disagree with the decisions made by the language team, what's left?

And no, "forking the language" isn't a real option.

[CyrusNajmabadi]

It's unfortunate. If we disagree with the decisions made by the language team, what's left?

as mentioned in a few other threads, an open option here is for you to just write an analyzer that blocks mutation of locals, unless they are marked in a particular fashion. This enables:

1. flipping the default, such that the shortest form of these declarations is the readonly one.
2. powerful customization for whatever rules/patterns/defaults you might want here. For example, you could just exclude something like for (int i = 0; ... as that's a normal idiomatic mutable local variable. Of course, this is up to you :)
3. Creating a feature that doesn't rely on a lang version. You'd be able to run this on every version of C#, and it would work on compilers for at least the last 10 years or so.

You could model this similarly to NRT< where you could even have things like ways to opt-in/opt-out on a per file or region basis.

[FrankBakkerNl]

It's unfortunate. If we disagree with the decisions made by the language team, what's left?

And no, "forking the language" isn't a real option.

The way I see it, the team has taken a lot of effort to analyse all the pro's and cons of all the proposed solutions for this. Based on that they have come to a solid argumented conclusion. Comments like this seem to suggest otherwise which I think is unjust.

The core of this dicussion seems to be about the preceived benefit of readonly locals. Some people think this benefit is quite large. I think this is mainly because it feels 'safer' and appeals to a specific (more functional) coding style. The team however has concluded that the benefit is actually very small and in no way outweighs the cost and downsides.

'What's left' is maybe to prove the team is wrong by gathering solid statistics of actual bugs in real life applications that would have been prevented if this feature was added to C#.

[Thaina]

It's unfortunate. If we disagree with the decisions made by the language team, what's left?

And no, "forking the language" isn't a real option.

There was occasionally some cases in the past that the team will change there mind and reconsider while forgetting they have been against the thing some years ago

It was my own faith, I believe we all voicing can swayed their opinion. But we just need time to hammering it into their subconscious. And wait until they forget they have against it in the first time. And then they would just presenting and championing something similar to the idea that actually good but they don't feel like accepted from us. That would be the time it was included in the language

How to hypnotizing them into accepting idea is mystery. Maybe we need to go deeper. Or there might actually be someone get in the plane bringing some potted seed along with them

[adamfk]

Looks like an analyzer is our best option right now. Has anyone designed what syntax would be ideal for this?

Maybe if we explore the analyzer route, it might change opinions. If successful, we all can move on. Just use the analyzer.

However, if the analyzer approach is fully explored and can't provide a reasonable solution, maybe the language team will reconsider.

Analyzer thoughts:

• Using comments to mark mutable or read-only/const is not ideal in my opinion.
• We also can't use attributes on local vars.
• So is it based on variable naming? Ex: int ro_age or int mut_count ? Read-only/mutable.

[jukkahyv]

You would use let in that case instead of const.
IMO using let is perfectly fine in cases where it makes sense.

I was trying to decipher: Even in TS, I write all variables as const

It seemed like even basic cases (like the above) would fall afoul of this. :-)

I don't know what to tell you. In my case, I rarely need mutable variables. Definitely not "never", but rarely. But it might be you write different kind of code.

[CyrusNajmabadi]

Indeed. But in the context of an analyzer or language change, these sorts of basic code examples matter.

[jukkahyv]

Or, you can have a wrapper class like

class Mutable<T>(T value)
{
	public T Value { get; set; } = value;
}

And then you can use that as mutable value. What I just meant to say is, you always have some workaround. How "nice" it needs to be, depends on how often you need that workaround. As I understand it, the C# team also said they prefer "readonly by default", so it's a question of whether mutable variables are needed 10%, 20% or 50% of the time.

[cprice404]

Wow, just went searching to see if immutable locals was on the roadmap anywhere and saw the language team response. What a huge bummer. C# is the only semi-modern language I've used that doesn't support this, such a basic and valuable feature.

I'm confused how the C# and TypeScript design teams can be so far afield from one another on something as basic as this. I hope they will reconsider but frankly, after seeing that this dragged on for 7 years before being rejected, just wildly disappointed.

Another reason to advocate for Rust in greenfield projects :)

[TahirAhmadov]

@cprice404 that's incorrect, C# does support it. You just have to use the analyzers feature to get it, as discussed in this thread at length.