While I'm not emotional on this, since this is a feedback thread :-), I'm with DavidArno. I think mutable primary constructor parameter is a bad choice.

My feeling is that, the designers eye more on the small classes scenario, where primary constructor fits nicely just like records, or senior library developers who absolutely know what they are doing. However, my gut feeling is that majority developers will use it for other scenarios: Half will be for dependency injection, 1/4 for domain objects with single constructor (DTOs use case can be replaced by records). Both are often big classes - there are more average developers than senior ones. And some classes will even span over multiple files by partial. And the code maintainer rotates. Mutation from a far away location is as tricky as mutation made by another thread, especially worse when you are reading an unfamiliar codebase.

Because fields are assigned prior to the method body being executed. Primary constructors don't change that.

There is a suggestion in#1026, but is it not being considered very positively?

That proposal hasn't really gone anywhere. I think the issue is that doing so will silently change the order of when certain fields are initialized, which will likely be unintuitive and surprising. It also creates a dependency problem as any member initializers that depend on that late-initialized member will also have to be late-initialized, including in derived types and possibly across assembly boundaries.

to handle a method call to a method that doesn't exist.

That's why I said using an intermediate call, sayInvokeFinalInitializer(object obj) - which is another function, whose implementation may be generated by runtime, while compiler merely generates that function with a dummy implementation - e.g. empty. Or better, the intermediate function could be a built-in function of the runtime.

Without special runtime support, the intermediate function would have to resort to reflection.

While I'm sure that's technically possible, I also don't think it would be palatable. There aren't any other features like that in .NET. It also doesn't solve for the addition of of a final initializer, unless the compiler emits such a call for every instance that is initialized.

In Scala, you can just write whatever statement you want directly in the class body.

Unless there's an option to extend this PC with a body, the applicability is limited to the Model and Service types and definitely not to UI modeling such as XAML and RAD interfaces.

I'm proposing an approach similar to that ofModule Initializer.

Define a Type Initializer attribute and allow the programmer to mark any (private instance) method with this attribute (a method that takes no parameters and returns void) since the whole type has access to the parameters of the PC, there's no need to take any explicit parameters.

The automation needs to invoke the method with this attribute in the source-generated constructor. And validate all the rules that apply to the constructor method as if it is the Proxy Constructor (even this abbreviates to the same PC).

@MadsTorgersen@KathleenDollard

@AndersKehlet , "if all you have is a hammer, everything looks like a nail"

Just about any feature you can think of can be done with generators. Unions? Why bother, just use a generator:

[Union]partialclassOption<T>{[UnionCase]privateNone__none;[UnionCase]privateT__some;}

And the reason why we don't just use a generator is that the code is pig-ugly, complicated and such non-standard, non-idiomatic code leads to splintering into dev camps. Just because a generator can be used, doesn't mean it should.

Generators should be seen as meeting the requirements of domain-specific features, not to bypass proper language design for generic features.

readonly parameters? Does that make sense to add to any ol' parameter list?

I think so, yes. Given the prevalence of captures in C# I think the ability to mark specific parameters and locals asreadonly would be beneficial to avoid accidental mutation of state. I'd prefer this to apply across the entire language, but given the scope of primary constructor parameter captures I think it makes sense to start there.

Creating a public property? Does that make sense to add to any ol' parameter list?

It already makes sense with primary constructions, given records.

The question (IMO) is whether language features are absolutely necessary for this, or if it could be solved in a satisfactory manner via analyzers and source generators. Like records, I do think this is deserving of first class support.

@DavidArno

Generating public members for PC parameters istrivial and it doesn't make the user code ugly.

Generating unions is technically possible for reference types, though I think the shown approach is questionable.

Generating unions that are also checked for exhaustiveness is, again, technically possible though in addition to the generator it requires a decidedly non-trivial analyzer.

Generating struct unions is... maybe possible? You could have an interface as the common type, but then you can't really guarantee the hierarchy is closed, so you lose exhaustiveness. There'd also be boxing.

The language proposal unifies all of this with a consistent syntax that is considerably simpler than what users can do.

@AndersKehlet I agree. :)

@CyrusNajmabadi - So... unions when? 😄

@DavidArno - btw, the reason I think your union example is bad, is that I wrote a union generator two weeks ago and the user code looks like this:

[AutoClosed]publicpartialrecordOption<TValue>{partialrecordSome(TValueValue);partialrecordNone;}

Needless to say, making the declaration syntax "pretty" is not why I want it as a language feature. Your other concerns are slightly more reasonable, though I think you exaggerate the issue with "non-idiomatic" code. I may have preferences, but I'm not gonna fortify myself in a camp. If I see an option or maybe type in a project, I'll immediately have a pretty good inkling of what it does, and I'll be comfortable using it (even though it'll likely be a mere pseudo-union, an abominable pretender).

As the property initializers run strictly after the constructor finishes (including derived ones), it seems that you are asking for a post-construction, post-property-initialization method. I think I’ve seen a proposal about such a method, but it was separate from the primary constructors.

Thank you@vladd for the clarification. Bottom line, conceptually, I am hoping for an ability to enforce "object construction invariants". It pains me a bit that currently if I want to do it, I cannot use primary constructors, because they don't have the body of a normal boilerplate-heavy constructor where I would usually put such invariants.

It would also be nice to makewith expressions work with that, but as you just clarified, this doesn't seem to be easy to do because the property initializers run after constructors, and I understand the prop initializers are used by thewith expressions.

Overall, looks like the language is adding various nifty features but because they don't work well together, I cannot really use them. Bummer.

I don't think putting full property declaration in primary constructor is a good idea.
Mutability of course but others no.

@yugabe That mistake seems hard to make. First, the IDE won't even recommend 'name' at all, once it is captured. Second, if you were to write that, you are immediately told:

Parameter 'string name' is captured into the state of the enclosing type and its value is also used to initialize a field, property, or event.

So i'm not sure how you're ending up in that state.

Thanks@CyrusNajmabadi, I didn't know there were analyzers for these. I remember there was talk about this around design, but wasn't solved yet then. Consider my fears alleviated.

@yugabe You're welcome :)

The feature has shipped. It is very intentional that it does not create a public member.

Sorry,@HaloFour, but the idea that I'd have to useprivate readonly to achieve a read-only capture is just awful. Private is the default throughout the language: let's keep it that way.

Edits to HaloFour's comment addresses this point, so it's retracted.

I was suggesting two separate features there, that could be combined.readonly to achieve readonly captures, and accessibility modifiers likeprivate to achieve promotion to a proper field. If you wanted readonly captures, but not a proper field, you would only usereadonly.

Updated example to show some combinations.

public Foo(init int bar) {   public int Bar {get; private set; } = bar;}

wondering ifinit could be used to limit usage of the parameter to initialization only (eg can't be used in another method)\

Maybepublic andprotected should create properties, andprivate should create fields?

@CyrusNajmabadi Thanks. I've seen it, but i wanted to give the feedback, since adding dependencies is not always a way that is available in every development environment

Not sure what you mean by adding a dependency :) SGs are something you can just author. They only generate code you would write yourself. Just in a way that is automated so you don't have to manually do it :)

Oh i just meant adding a nuget package which has the source generator as "dependency". obviously it's not really a dependency per se, but a package that is added to the project. I sometimes have customers who are very restrictive with package references

@taori this would be for your own benefit. This would not be shipped to your customers. This is about addressing hte point you made about: Sometimes i have 5-15 DI services for UI classes, and from an intellisense perspective _someService just gets my intellisense into a direction way faster.

For your local library/app development you'd use a generator to take care of that drudgery. But you wouldn't be shipping anything new (esp. nuget-wise) to your customers.

Note: This is how Roslyn itself works. We have generators that take care of stuff for us. But we dont' ship the generators to customers. We only ship our normal compiled libraries, which contain the compiledoutputs of the generator.

You could use a source generator that automatically emits code to initialize fields using any name you want. It could be paired with an analyzer that then makes it an error to reference the parameter as a capture outside of the construction lifecycle.

I see C# 12 primary constructors as syntactic sugar to have trivially simple automatically initialized fields.
Having to write a source generator to address something many developers use (starting their private fields with an underscore) sounds no longer trivial.

I see C# 12 primary constructors as syntactic sugar to have trivially simple automatically initialized fields.

That is not correct. They are just another way of defining a constructor with parameters. Just with parameters that can be used by the members nested within the type/cosntructor.

Having to write a source generator to address something many developers use (starting their private fields with an underscore) sounds no longer trivial.

It's trivial to just use that (and have other developers use it) once written once.

Ah, the old "you don't need a seat belt. Just don't crash your car, and you'll be fine" line of reasoning 😂

Given such a small incidence of this actually happening, I'd say that is fairly accurate. You don't need every safety measure. Not if it's not really that necessary or valuable.

@DavidArno I do use a seat belt, but I do not use a helmet when driving. I assume you do.

@baterja the exact purpose of using records is precisely to get members and proper behavior around those Members. When using a non-record type we don't want that since that's what records are for in the first place.

I know, but only because I've been using C# for over 10 years and was up to date when those changes were introduced. Newcomers think primary constructors will behave alike in records and not-records, and also becauseTypeScript allows similar syntax (class X { constructor(public readonly x: number) {} }). So I consider it counter-intuitive.

TypeScript primary constructor syntax involves providing an accessibility modifier.

The behavior of primary constructors in C# is identical to that in Scala and Kotlin, and it's not considered confusing in either of those languages. It's expected that if you want the class to behave as a data carrier and define the schema of that data based on the constructor that you need to opt-in to that by making the class an equivalent of a record, viacase ordata.

Why do you use therequired keyword if you are providing a value from constructor? Either remove therequired keyword or provide value via object initializer and it will compile.