Preview Feedback: C# 12 Primary constructors

[KathleenDollard]

Primary Constructors for non-record classes and structs are included starting in C# 12 in preview 3. You can use this discussion for feedback as you use the feature.

You can learn more about primary constructors in non-record classes and structs at the What's new in C# 12 article with links to all new content for primary constructors.

[HaloFour]

I kinda wish the blurb under "What's New" was a little more fleshed out, particularly as it describes the interplay with primary constructors with "record" and which feature contributes what behavior. The documentation linked under "Instance constructors" is much more explicit and hopefully will be enough to dispel the confusion that has already led to comments in the discussions regarding member synthesis.

[KathleenDollard]

Do you mean in docs? I really rushed @BillWagner to ensure we had a link. There will be more, and as usual Bill will integrate the new feature with our broader docs, so a year from now you don't have to sift through "what's new" for details.

[mstefarov]

If I'm understanding this correctly, the new primary constructor syntax forces using the same name for both fields and parameters. This seems like an awkward limitation, because naming guidelines for fields and parameters are usually different (e.g. for dotnet codebase itself). I don't really see myself adopting this feature if it forces inconsistent naming. That would just make the code harder to read.

[HaloFour]

the new primary constructor syntax forces using the same name for both fields and parameters.

Primary constructors don't create fields. They are parameters which can be captured if used beyond the lifecycle of the constructor. The method of capture is an implementation detail, but likely a field with an unspeakable name.

[jaredpar]

@HaloFour is correct, this doesn't force any relationship between parameters and fields. Completely fine to do the following:

class C(string name1) {
  string Name2 = name1;
}

[zimpzon]

class C(string name1) {
  string Name2 = name1;
}

With this code be have both the Name2 and name1 variable in the full class scope. That just makes things worse, doesn't it?

[zimpzon]

Whether or not a class field is created is an implementation detail, we can use the ctor parameters just as if they were class fields. Some way to discard name1 from the class scope would be a requirement for me. Or any other working solution for the scope pollution problem, of course.

Example (init keyword):

class C(init string name1)
{
 private readonly string _name2 = name1;
 public string GetIt() => name1; // name1 should be undefined here.
}

...or I would just stick to the standard ctors of course, VS is just aggressively suggesting everywhere that I use primary ctors.

[chrisoverzero]

Or any other working solution for the scope pollution problem, of course.

The compiler will right now issue CS9124 for that code sample. (Minus the init, natch.)

[andrew-vdb]

The document miss use cases when do you want to use this feature, something like before and after, not the conversion of the code per se, more to what we are trying to tackle.

[jaredpar]

It's an improvement over how I needed to do it 4 times, but it's certainly not as close to TypeScript's version of defining it only once

Keep in mind, while in many cases developers will want to expose parameters of primary ctor as properties of the same type, that is not the 100% case. Developers will often want different types, switching the name (consider casing differences on parameters vs. properties), do modifications, etc ....

The feature here is what provides the fundamental tools needed for primary constructors while allowing us to extend them in the future to provide items like property support, dual names, etc ... Those features though have a lot of design issues around them while the fundamentals do not. Better to get the fundamental feature out now, get feedback, and evolve again in the next release.

that inside the class, you have access to BOTH FirstName and firstName, which will only cause confusion and won't help IntelliSense usage either...

That is a fundamental property of primary ctor in pretty much every language that defines them. C# is not different here.

[CyrusNajmabadi]

but it's certainly not as close to TypeScript's version of defining it only once

Nothing about the current form of primary constructors limits or prevents such improvements down the line. We like to build up these things in a granular fashion of small, composable, language features. This version is expanding the the core primary constructors feature to go beyond records to normal types. Additional changes here are totally possible depending on the team and the communities desires around there. If you're interested in future capabilities expansions for primary constructors, i def recommend you add feedback to existing discussions, or even open new discussions on where you'd like to see it go :)

[yugabe]

I really do appreciate how you guys have really thought this through. And while I'm usually pretty much in the "for" camp when new language features arrive, I'm having trouble understanding the motivations here.

When records got primary constructors implemented, it was already weird to me why wasn't the same already being applied for classes (or maybe even structs). Now, it seems, the primary constructors is becoming this catch-all to let everyone define everything everywhere? I think when things like

Developers will often want different types, switching the name (consider casing differences on parameters vs. properties), do modifications, etc ....

is exactly what overcomplicates the problem. There is nothing "wrong" with how constructors work at the moment in C#; there's a fully working way to do all of those right now. The primary constructors of records could have been repurposed, but instead a whole new direction is introduced with this change. There already was a problem when using records if the user wanted to define different types of properties instead of the default. Casing conventions got thrown out with the bath water as well, because those "parameters" became "Properties". So I believe the current implementation, while may be forward-facing, doesn't currently address the primary issue for why people were asking for them in the first place.

As far as I know, the leading motivation for primary constructors was that it was easier to define property layouts for objects and reduce the duplicated code required when passing constructor parameters to those properties. If I understand this wrong, my presumption was wrong. If not, the current implementation doesn't really solve the problem, but creates other problems that were not there before. Increased cognitive load is not something to ignore. I think, nor is the pollution of variable context in methods.

If primary constructors won't solve the problem of reducing the boilerplate of assigning a constructor parameter to a property, it's weird then that is was the problem that was being solved when defining records.

I think something like

public class MyClass(
    public string MyCtorString { get; set; },
    private int MyCtorInt { get; }
) { 
    public required string MyInitString { get; init; }
}

would have solved the problem much better. But again, if I wanted to solve other problems than the team, it's good as well. But this is where you asked for feedback, and I appreciate it is being heard.

[HaloFour]

Records are data carriers, so it makes sense that the primary constructor is promoted to public properties. Normal classes are not data carriers, so it doesn't make sense to automatically affect the public surface of the type. It is the "record" feature combined with primary constructors which results in the properties being synthesized, as well as deconstruction.

There isn't a new direction here. Primary constructors do one thing, records do another thing. The primary constructor behavior when combined with record member synthesis is what enables the behavior you see with positional records today.

[jaredpar]

If primary constructors won't solve the problem of reducing the boilerplate of assigning a constructor parameter to a property, it's weird then that is was the problem that was being solved when defining records.

It demonstrably reduces the boilerplate and I gave examples of that in this very thread. Yes there are opportunities to reduce it more by making it easier to declare members and it's likely that we'll explore that in future language releases.

Keep in mind though that there is not a one size fits all for how parameters should map to members. Consider all the variations that need to be considered:

1. Map them to properties or fields?
2. Map them as mutable or readonly?
3. Do we provide a syntax to have parameter name and member name be different casing?

Records were able to get away with the automatically mapping to members because they are a highly opinionated data type. They are immutable by default, equatable, withable, etc ... That provided answers to all these questions. Keep in mind that while records are popular and useful in a lot of scenarios, these decisions made records unsuitable for a number of scenarios.

Primary constructors are meant to be a much more general purpose feature and applicable to a significantly more scenarios. That means taking a stance like "always promote to property" is not acceptable because it will exclude too many scenarios. Instead we have the base feature now and are looking to future versions where we can expand on the syntax to have features like properties, fields, etc ...

[yugabe]

I think the primary constructors miss most of the pain points developers have when writing constructors. Consider a common Service class, which take different dependencies as required parameters in their singular constructor.

public class Service1
{
    private Service2 Service2 { get; }
    private Service3 Service3 { get; }
    private Service4 Service4 { get; }

    public Service1(Service2 service2, Service3 service3, Service4 service4)
    {
        Service2 = service2;
        Service3 = service3;
        Service4 = service4;
    }
}

Boilerplate on boilerplate on boilerplate. I typed Also very common. The current primary constructors don't really solve this problem, almost at all. Additionally, introducing class-level closures is not at all beginner-friendly and not even intuitive at all for us oldies.

Consider TypeScript, on the other hand:

class Service1 {
    constructor(private service2: Service2, private service3: Service3, private service4: Service4) {
    }
}

Simply putting the visibility modifier in front of parameters make them properties. Transpiled to JavaScript, this will actually set the fields (no need to "define" them in JavaScript) first thing in the constructor body.

---

There's no need, nor do I see any benefit for the primary constructors to behave as closures. I won't define a parameter I don't want to use in the class. I want to, almost always, set a property on the class, just as records do.

It would be a lot better if C#'s implementation was more similar to TypeScript's. I could also imagine the primary constructors to take auto-property declarations or similar. This would allow for get-only or get-set properties to be defined. Or just make them readonly fields and be done with it.

I think either allowing more customization or intentionally limiting the scope should be a focus. This is not a good feature in its current state in my opinion. It adds more cognitive load to see if there are any properties/fields/primary ctor parameters are there. The goal should be to make defining classes easier, so I don't think full customization should be available.

[HaloFour]

Technically true, but I somehow doubt that the average user is going to do that. ;-)

The suggestion isn't that each developer needs to learn how to write analyzers and then apply this to their project. It would only take one person to write such an analyzer and to publish it to NuGet for the entire community to benefit.

[HeinziAT]

Or Microsoft could add such an analyzer and ship it with this feature: Visual Studio Options/Text Editor/C#/Code Style already has a section for "Parameter preferences", which currently only contains "Avoid unused parameters". A second option "Avoid modifying primary constructor parameters" (maybe with a low default severity of "Info" or "Warning") would fit in there nicely.

[CyrusNajmabadi]

Technically true, but I somehow doubt that the average user is going to do that. ;-)

You don't need the average developer to do it. You just need a single interested party to do it once, then any developer can pick that up.

[CyrusNajmabadi]

@Sebosek please keep things constructive and considerate. Unnecessarily caustic behavior violates our code of conduct. I've hidden your post for now. Feel free to revise, and we can bring it back. Thanks.

[NPSF3000]

Lots of good discussion here, and I'm a tad rusty... but seeing this example above really excites me:

public class Service1(Service2 service2, Service3 service3, Service4 service4)
{
    public void SomeMethod()
    {
        service2.DoSomething();
        service3.DoSomethingElse();
    }
}

I'm always a huge fan of reducing boilerplate and allowing developers to express themselves succinctly and powerfully. This could be really powerful for standard IoC services.

[En3Tho]

Please correct me if I'm wrong but I'm not seeing how primary ctor body is used. E.g. ctor-time parameter validation, non-static field initialization, etc. This is one of the things I'm really missing in records too.

In F#, for example, your type's body is a primary ctor body basically. This makes initialization in primary ctor very convenient.

[markushaslinger]

Based on some initial testing in SharpLab my major concern is mutability. I understand that parameters are always mutable and this would be an exception to that rule, but in this scenario the scope is so much wider: for a normal parameter it is the method body, in this case it is the whole class.

That can quickly lead to, not that obvious, state change (and confusion with a local variable one might have forgotten to declare).
I'm thinking in an educational context where I can see my students struggle with that issue right away.
A primitive example:

var foo = new Foo(2);

Console.WriteLine(foo.Baz()); // 4
Console.WriteLine(foo.Baz()); // 8

class Foo(int bar){
    private int Bar {get;} = bar;
    
    public int Baz()
    {
        var qux = Bar * bar; // now I have an additional backing field
        bar = 4; // and it is mutable
        return qux;
    }
}

Personally, I would prefer immutable by default (yet I would also prefer property instead of field by default), but I get that would be a deviation from the general rule as well.
However, you could at least allow us to do Foo(readonly int bar), which could also be enforced by a style rule, to at least prevent mutation. At this time we could use Foo(in int bar) which gives immutability but passes by reference which digs an even bigger hole (not a serious suggestion).
So I would really like to see readonly support in the first version of the feature. At this point I'd probably restrict usage otherwise, which is kind of sad.

I would also suggest naming to be _foo instead of foo to give a better indication that we are creating a field, but since that is a naming convention only it can be handled (and rule-enforced) on a team level, so a lesser issue.

One last comment to the reduction of boilerplate with DI: I only write readonly IService _service; and then hit Alt+Enter,Enter (or whatever your quick-fix choice is) and get the constructor, with parameter and assignment generated. So, this feature does not really reduce my typing effort, but it does removes the many LOCs of ceremony at the start of the class - especially if there are many, say four or five, dependencies. I wouldn't rank it top priority as language features go, but I can see the benefit here - if we can get mutability under control.

[markushaslinger]

I know that if I can see the issues your team obviously does as well. Just as I am sure that you also realize that the problems are much exaggerated by the larger scope (every method in a class is affected instead of only one).

I fully agree that a general solution for all parameters/ctors is desirable and will hopefully arrive in a future version.

Based on your responses I get the impression that the team has already settled on shipping in this state, so I'd like to ask that you at least provide an optional diagnostic, to disallow the feature, out of the box, until the remaining features arrive to make it a truly nice addition.

[CyrusNajmabadi]

so I'd like to ask that you at least provide an optional diagnostic, to disallow the feature, out of the box,

This is already supported in roslyn. You can already write analyzers to produce optional diagnostics and disallow any features you, your team, or your organization does not want to use. Analyzers are supported out of the box and were created precisely for this purpose, allowing anyone to produce any rules they want for how the language should be restricted in their domain.

[markushaslinger]

I know I can do that, but I was (sneakily) hoping for an official csharp_style_ or similar...

Don't get me wrong, I'm thankful for your work - C# is an amazingly productive language and my favorite by far. And usually, I'm all for new features, because of new possibilities.
But with this feature, in this state I already see myself and colleagues doing lots of explaining and bug hunting the moment we introduce classes after only working with records before that and students trying to add a primary ctor as they are used to but then get different behavior and then the problems will come. So, please forgive me if I attempt preemptive damage control :)

Maybe you can consider increasing priority for the general parameter mutability / primary constructor features for future versions. Even if repeating myself: I strongly feel this needs more options rather sooner than later.

[CyrusNajmabadi]

but I was (sneakily) hoping for an official csharp_style_ or similar...

We don't generally make csharp_style_ options that restrict new features. :)

So, please forgive me if I attempt preemptive damage control :
I already see myself and colleagues doing lots of explaining

Sounds like you have the right approach already to ensure no damage :)

Maybe you can consider increasing priority for the general parameter mutability / primary constructor features for future versions.

Sure. I'm personally very motivated on making it easy to have these be readonly.

[markushaslinger]

We don't generally make csharp_style_ options that restrict new features. :)

Well, it was worth a shot ;)

I already see myself and colleagues doing lots of explaining

Sounds like you have the right approach already to ensure no damage :)

If they'd listen...

Maybe you can consider increasing priority for the general parameter mutability / primary constructor features for future versions.

Sure. I'm personally very motivated on making it easy to have these be readonly.

Great, thanks!

[epeshk]

Suppose, we need to add some validation for primary constructor parameters, e.g. check that it is not null or empty:

public class NamedItem(string name)
{
  public string Name => name;
}

To do this, we have to go back to the old syntax (5 lines added):

public class NamedItem
{
  public string Name { get; }
  public NamedItem(string name) // <-- ctor parameters moved
  {
    ArgumentException.ThrowIfNullOrEmpty(name);
    Name = name; // <-- assignment moved because the scope of the name parameter has changed
  }
}

This can be done automatically by the IDE, but writing a primary constructor and then converting it to a simple constructor at some point is not nice. This is also a pain for records.

Kotlin solves this with an init block. Although init method looks like a non-primary constructor, it reduces amount of changes during refactoring.

Example with init method (1 line added), how it might look in C#:

public class NamedItem(string name)
{
  init() => ArgumentException.ThrowIfNullOrEmpty(name);
  public string Name => name;
}

[epeshk]

@DavidArno @CyrusNajmabadi is not null or ?? check only for null, not for emptiness. It should be: string.IsNullOrEmpty ? name : throw ...;, or with extension method: name.ThrowIfNullOrEmpty()

Yes, it is possible to workaround validation is simple case, but init helps to keep all the logic in one place.

[CyrusNajmabadi]

@epeshk i'm totally fine with an init based approach. But, as i mentioned higher up, i like these as orthogonal features that users can compose. :)

[Richiban]

In your code example, validation is easily handled (updated to a simpler form suggested by @CyrusNajmabadi):

public class NamedItem(string name)
{
  public string Name {get;} = name ?? throw new ArgumentNullException(nameof(name));
}

It's currently possible to "hack" primary constructor validation when the constructor parameters aren't exposed as properties by using a private property:

public class C(string s1, string s2, string s3) 
{
    private int _ {get;} = (s1, s2, s3) switch {
        (null, _, _) => throw new ArgumentNullException(nameof(s1)),
        (_, null, _) => throw new ArgumentNullException(nameof(s2)),
        (_, _, null) => throw new ArgumentNullException(nameof(s3)),
        _ => 0
    };
}

but it world be really good to be able to replace that hack with an init block like you suggest.

That form gets a big thumbs down from me I'm afraid, because the validation happens on value access instead of class construction, violating the Fail Fast principle I personally hold dear.

Not to mention the fact that your validation might be somewhat expensive (such as a wrapper type representing a string conforming to a particular regex) and therefore should run only once, instead of repeatedly validating the same piece of data :/

[HaloFour]

@Richiban

That form gets a big thumbs down from me I'm afraid, because the validation happens on value access instead of class construction, violating the Fail Fast principle I personally hold dear.

Member initializers occur during construction.

[Richiban]

@HaloFour Oops! Quite right; I misread
public string Name { get; } = name ?? throw new ArgumentNullException(nameof(name));
as
public string Name => name ?? throw new ArgumentNullException(nameof(name));, because I personally never use the former. How embarassing.

[HeinziAT]

(As suggested by Kathleen, this is a copy of the comment I left on the announcement blog. I apologize for the verbosity, it was originally meant as a chatty blog comment conveying a first impression, not as well-researched, targeted technical feedback.)

---

First, I’d like to thank you for continuing to improve C#. This continuous improvement is the main reason we switched from VB.NET to C# some time ago. (Nullable reference types and record types are awesome, and I’m already looking forward to all language features that help reduce INotifyPropertyChanged boilerplate.)

That having been said, I share the skepticism around primary constructors for non-record types. I’ll try to explain why:

1. They add a lot of complexity to the language, since they look like the primary constructors of record types, but behave differently in a non-obvious way. That would be OK, if they were a long-awaited feature solving an important problem.

2. But are they? I have a hard time coming up with a use case for them. If I write (a) a simple data container class, I’ll just use a record type. On the other hand, if I write (b) a complex class, my “main constructor” doing all the initialization is usually private, invoked by other (simpler) constructors or (well-named) factory methods. I seldom have complex, non-record classes where the “main constructor” is public.

3. Which leads to another (minor) point: The primary constructor is public, which is a deviation from the long-standing principle in C# that “no accessibility modifier” means “the least accessibility that makes sense”. Yes, I am aware that making it private by default would be awkward as well, and I don’t have an elegant solution either. It’s just that C# is such an elegant language that adding stuff which does not feel elegant just seems… wrong. (It’s OK and “feels right” for record types, since they are special types for a specific purpose.)

There’s one caveat to my criticism: I don’t (or rather: very seldom) use “constructor dependency injection”. Some have speculated here in the comments [note: meaning the blog comments] that this is the intended use case for this feature. If this is the case and it solves a real problem: That’s great, please ignore my comment, proceed, and don’t let me stop you. If it isn’t: What use case did you have in mind for this feature? Which common problem is it supposed to solve that justifies the cost?

---

Addendum: Point 3 (the accessibility of the primary constructor) might be a bigger issue than I originally thought: Jared wrote in a comment further up that you want to "get the fundamental feature out now, get feedback, and evolve again in the next release". The thing is: You won't be able to change the default accessibility of the primary constructor without a breaking change to the language.

[HeinziAT]

It is the record keyword that adds the additional functionality [...]

Yes, seeing record primary constructors as a special case of non-record primary constructors (rather than the other way around) helps. Thanks.

There is an accessibility modifier, the modifier of the class itself. If the class is public, then the primary constructor is public. If the class is internal, then the primary constructor is internal.

And if the class is (nested) private, the primary constructor is private? That would be an odd choice.

I just tried it with SharpLab, and, apparently, primary constructors are always public.

This kind of emphasizes my point about non-obvious things happening. If primary constructors manage to confuse even you about their accessibility, how are we mere mortal developers supposed to have a chance? ;-) As a library developer who has to deal with backwards compatibility on a daily basis, I'm deeply skeptical about "public by default" things, especially if it it's not immediately obvious that they are public by default.

[...] the docs for dependency injection for ASP.NET pretty much exclusively follow the pattern facilitated by primary constructors.

Makes sense, thanks for the example. And for this use case, a public constructor is obviously the right thing.

[CyrusNajmabadi]

how are we mere mortal developers supposed to have a chance

Try the feature and see what happens? Read the documentation? I'm not sure how this is any different from anything else that we've added to the language. It always invariably requires learning how things work and then utilizing appropriately for a particular set of problems.

I'm deeply skeptical about "public by default" things

Then this feature would likely not be for you. But, for example, just looking at something like Roslyn itself, a ton of our constructors are public, and either:

1. initialize exported state.
2. initialize non-exported state.

That's a huge codebase with a public surface area, that would still find this useful for some (not all) cases to clean things up.

--

I think a core issue here is that people see a new feature and are not happy that it's not useful/viable for every single use case they can envision. But that's not a core goal for these features. If you want something useful/viable for every use case, you use the 'full fat' features that expose all the knobs, but also have the most verbosity associated with them. The point of these syntactic conveniences is to be really good at a subset of things, and to compose well with other features (both from the past, and coming in the future). When your domain intersects the things they do well at, you can use them. When they don't, you don't :)

It's very similar to how C# works with properties. In C# 1.0 you could only write: public string Prop { get { ... } set { ... } }. But over time nicer and nicer forms were added to work in addition to the original form. In no way were the new forms intended to replace the old one. Rather, they act as a complement to them, allowing the convenience when you need/want it, but the full-featured fallback when you need that.

This has been a core principle for the language since inception. Common patterns get more convenient shorter forms. But those shorter forms are generally always limited over the full forms in some way.

[HeinziAT]

@HaloFour: About your ASP.NET example: I'm not sure primary constructors (in their current form) are a good fit for that either: Currently, _service1 is readonly. We have a class invariant that _service1 will always refer to the same object. After rewriting it with primary constructors, this is no longer the case.

@CyrusNajmabadi: You wrote that it's a "core principle for the language" that the language gradually gets nicer and shorter forms for common use cases. I fully agree. But another design principle of C# is for it to be a pit of success language: It's easy to do the right/safe thing, and it's hard to do the wrong/unsafe thing.

In Halo's ASP.NET example, we just replaced a "safe" immutable field with an "unsafe" mutable captured variable.

Now, you might argue, "if you don't like that, don't use it". Well, I remember when VB.NET first got auto properties: It was easy to create readonly fields, it was easy to create mutable properties, and it was hard to create readonly properties. Not surprisingly, people started to create readonly fields or mutable properties in cases where a readonly property would have been "the right thing to do". (This got fixed eventually - somewhere around 2015, VB.NET started supporting the ReadOnly keyword for auto properties.)

[CyrusNajmabadi]

It's easy to do the right/safe thing, and it's hard to do the wrong/unsafe thing.

Given how well parameters have worked so far as being right/safe, i'm good with primary constructor parameters working the same way. I think the language could provide more guardrails in the future if truly necessary. We can easily just see how things work out in the next release. In the meantime, if people want guardrails today, writing an analyzer for this task would be fairly trivial and fun :)

[HaloFour]

@HeinziAT

Yes, the captures would now be mutable. Unless you're trying to assign to it that should not be a problem. They don't need to be readonly for DI to work. In lieu of potential language features to mark the parameters/captures as readonly in the future, an analyzer can be used to forbid reassignment within the class, if desired. Or a source generator can be used to automatically emit readonly fields along with their assignments from the primary constructor parameters.

I don't want to sound dismissive of your concerns, I too would prefer to have the ability to explicitly mark these parameters as readonly in the language.

[WhitWaldo]

Just throwing my own two-cents onto the primary constructor pile: I usually can't use the primary constructor on records (or now classes) because I also have to define a parameterless private constructor for DataContract de-serialization purposes.

Might it be possible to augment types that use the primary constructor to automatically generate a parameterlesss private constructor either when a record is decorated with a [DataContract] attribute or otherwise via a project-level configuration flag? Because as it stands, I have to entirely opt out of using primary constructors everywhere since I have to instead define two secondary (?) constructors instead, one public and one private.

Thanks!

[HaloFour]

A source generator could do that.

[CyrusNajmabadi]

because I also have to define a parameterless private constructor for DataContract de-serialization purposes.

That seems odd. We have tons of records in roslyn that use datacontract. For example:

[WhitWaldo]

I just went and hunted down the StackOverflow answer I'd relied on that indicated I needed a parameterless constructor for way back when and have just pleasantly found that you're spot on - it doesn't use the constructor at all while deserializing (contrary to what I'd thought), so nothing but the [DataContract] attribute is required.

You've saved me a ton of future typing and I look forward to using these primary constructors more going forward! Thanks @CyrusNajmabadi !

[CyrusNajmabadi]

You're welcome!

[tzajac]

I think this feature works well in a lot of cases. I would like to see two improvements.

The first would be allowing to add a method body for the primary constructor.

A second improvement would be to allow the Primary constructor parameters to be "in" parameters.

public class ServiceA(in Service1 service1, in Service2 service2) //Allow the "in" modifier. Make the backing fields read only.
{
    PrimaryConstructor{
            //Allow the class to do any additional logic with a primary constructor method body
    }
}

[CyrusNajmabadi]

this is the init lang extension concept for allowing code to run post construction.

[jaredpar]

A second improvement would be to allow the Primary constructor parameters to be "in" parameters.

This is disallowed for the same reason that ref is disallowed. A primary feature of primary constructor parameters is they are capturable as written. In order for ref or in to be capturable then one of the following would be required:

1. The are captured as ref / in fields. That limits them to only being usable in ref struct and ref fields have a lot of restrictions because they are a very advanced concept. Having one be implicitly created is not something I'm personally eager to do.
2. They are captured by value. Essentially their field type becomes the parameter type when the ref / in is removed. That is also a bit dicey because it means where the developer uses the reference changes whether it's a ref or a value. That is fairly subtle and could lead to bugs particularly when struct are involved.

Neither of those is very attractive from a capture standpoint.

The other approach though would be to allow them but not allow them to be captured. Essentially ref / in parameters can occur in a constructor but cannot be used in a way that they are captured. That removes the issues I listed above and doesn't introduce any odd / subtle semantics. But it does create of a bit mixed message about whether primary constructor parameters are / aren't capturable. I'm unsure if the extra complexity in the message is worth the flexibility but it's an area I'm open to if there are compelling samples.

[thisisnabi]

We need readonly properties in dependency injection, will support for this feature be available?

internal class CreateCustomerCommandHandler
(ICustomerRepository customerRepository, IMapper mapper,  IUnitOfWork unitOfWork)
    : IRequestHandler<CreateCustomerCommand, ErrorOr<CreateCustomerDto>>
{

}

[voroninp]

@KathleenDollard asked me to post it here:

One more thing which concerns me with PC.
If I substitute class for record then constructor arguments automatically become properties but named in camelCase style.
What if later you decide for the same semantics of records, that is for having init/readonly property?

I’d propose having an opportunity to distinguish these two cases: properties vs private/protected(?) readonly (?) fields.

Readonly/init properties:

public class Student(int Id, string Name, IEnumerable<decimal> Grades) { ... }

Declared as readonly private field.

public class Student(int `id, string `name, IEnumerable<decimal> `grades) { ... }

OR

public class Student(
    private readonly int _id, 
    private readonly string _name, 
    private readonly IEnumerable<decimal> _grades)
{
   ...
}

Declared as protected readonly field

public class Student(int #id, string #name, IEnumerable<decimal> #grades) { ... }

OR

public class Student(
    protected readonly int _id, 
    protected readonly string _name, 
    protected readonly IEnumerable<decimal> _grades) { ... }

The versions with explicit modifiers are verbose. I guess readonly is desired in 99% cases, so, I’d allow yet another contextual keyword mutable:

public class Student(int `id, mutable string #name, IEnumerable<decimal> `grades) { ... }

Visibility modifying prefixes # or ` should affect only how names are visible inside the class, for constructor callers # and ` should be dropped:

public class Student(int `id, mutable string #name, IEnumerable<decimal> `grades) { ... }

is equivalent to

public class Student
{
    private readonly int _id;
    protected string _name;
    private readonly IEnumerable<decimal> _grades;

    public Student (int id, string name, IEnumerable<decimal> grades) { ... }
}

P.S.
I suggested # and ` intentionally, because in any other context they will yield invalid identifier, thus if one changes class to record he immediately gets the error from the compiler.

[markushaslinger]

With this version they will do mutable as default (aligned with how parameters work elsewhere), so making immutable the default later won't be possible without breaking existing code => won't happen I guess.

There also won't be additional modifiers (readonly, private,...) available for now, but those features are planned to get added later.
I expect that we will be able to write ServiceA(private readonly ServiceB _serviceB) eventually - verbose, but explicit. Until then an analyzer to prevent usage of the feature or possibly to ensure the parameters are used exclusively for assignment to properties (and not used as fields) seems the way to go.

Side note: I suppose most agree that 'mutable by default' was not the right decision (same as 'open by default' vs. sealed), but those decisions were made a long time ago under different circumstances. Changing that now would be too harsh a break imho.
Maybe we'll see a 'Kotlin event' someday where a new-ish 'C#++' .NET language turns up, keeping the good stuff but with defaults more aligned to how we write programs today to reduce boilerplate.

[begerard]

It's interesting to duplicate this functionality from record to class, I do sometimes used records exclusively for this, which is not ideal.

But please do not implement it differently. This will add obvious pitfalls if we have auto implemented props in one case but not in the other, and hidden backing field in a case and not in the other. You are explicitly doing this functionality as a replica of the record's one, so yes, if there are differences, in a way you are explicitly hurting us.

I'm down voting this one as I'm sure it will make my usage of C# harder and I'll have to fix bugs caused by this confusing implementation. I'm even convinced that my misusage of records is better than this.

Primary constructors don't create fields. They are parameters which can be captured if used beyond the lifecycle of the constructor. The method of capture is an implementation detail, but likely a field with an unspeakable name.

@HaloFour Developers are impacted by implementations. Lambda is a special beast with its capture problems, I have learnt the hard way that I better not ignore them, and it's the same here.

[HaloFour]

But please do not implement it differently. This will add obvious pitfalls if we have auto implemented props in one case but not in the other, and hidden backing field in a case and not in the other. You are explicitly doing this functionality as a replica of the record's one, so yes, if there are differences, in a way you are explicitly hurting us.

Implementing it differently is intentional. Records are data carriers, so it's expected that the values are to be exposed publicly. That's not the case with normal classes. Generating public properties by default affects the surface of the type in ways that would make it unsuitable for many (if not the majority) of the use cases in which case this would be useful. For example, you wouldn't want to expose the dependencies in a DI scenario. It's the combination of the two features which is what allows records with primary constructors to behave as positional records.

Records in C# are pretty much identical to data classes in Kotlin and case classes in Scala, which have this same duality, and this has not proven to be confusing in either of those languages. Like any new feature, it's something you learn once.

[begerard]

Every time I come across a primary constructor, I'll have to check if it's a class or record to know what it will do. It's understandable but it's a new layer of complexity, no functionality with the same side effect come to my mind. Maybe I'm too conservative, but I doubt it worth it.

[HeinziAT]

@begerard: That was also my initial reaction, but, after reading all the discussions here, I also feel that it won't be a problem. What helped me was to think of primary constructors as only the feature proposed here (captured parameters), and to think of records as a special case. Records automatically add a lot of things (value-style comparisons, for example), and automatic public properties for the captured primary constructor parameters are just another one of those things.

[Richiban]

Every time I come across a primary constructor, I'll have to check if it's a class or record to know what it will do.

While that's true, the primary constructor and the class / record keyword are always going to be right next to each other, meaning you'll almost certainly take them both in in a single pass when reading. I very much doubt that's going to be a problem.

[windows-live]

I didn't expect my idea to have such a big response.  I just want to express my thoughts and hope that these ideas can bring another kind of inspiration to everyone. So what should we do now?  Can deleting this post now solve the problem

…

------------------ 原始邮件 ------------------ 发件人: "dotnet/csharplang" ***@***.***>; 发送时间: 2023年5月25日(星期四) 晚上8:50 ***@***.***>; 抄送: "windows ***@***.******@***.***>; 主题: Re: [dotnet/csharplang] Preview Feedback: C# 12 Primary constructors (Discussion #7109) The majority of the had been considered by the team during the design of the feature. If all of this had been considered beforehand, why invite feedback? The decisions are made, so don't give the users the false impression that the team cares what those users think. While I understand that other people have the same concerns, bringing it up without additional information doesn't really change the equation. There are literally hundreds of comments here with reams of additional information. Non sequitur. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[windows-live]

Sorry, I would like to express a profound apology first.  I did not expect such serious consequences to occur, but I just wanted to express some ideas and hope that these ideas can bring another kind of inspiration to everyone.  I didn't expect the consequences to be so serious, and I am very sorry

…

------------------ 原始邮件 ------------------ 发件人: "dotnet/csharplang" ***@***.***>; 发送时间: 2023年5月25日(星期四) 晚上9:21 ***@***.***>; 抄送: "windows ***@***.******@***.***>; 主题: Re: [dotnet/csharplang] Preview Feedback: C# 12 Primary constructors (Discussion #7109) @DavidArno If all of this had been considered beforehand, why invite feedback? The decisions are made, so don't give the users the false impression that the team cares what those users think. More feedback. There's always things that may not have been considered or puts a different angle on things. Numerous proposals have been amended at this stage due to community feedback, if not outright canceled. The responses to the feedback isn't to dismiss it, it's to explain why the team reached the design that they did. But this is late-stage feedback at this point so the proposal does have quite a bit of inertia behind it. There are literally hundreds of comments here with reams of additional information. Non sequitur. Repetition alone is not new information. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[windows-live]

`var emp_primary = new Employee("冯", "先生", "56820168@qq.com", 75000) by ~;

It might be more appropriate to change it to something like this

var emp_primary = by ~ new Employee("冯", "先生", "56820168@qq.com", 75000);
`

Recently, I am busy with work and rarely log in GitHub
At that time, I just wanted to share my ideas and hope that these ideas will bring people another kind of inspiration. I didn't expect that they would resonate so much. Thank you very much for people enthusiasm, please don't take these demonstrations as tutorials. This is not a tutorial, it's just a demonstration. Expressing my ideas through this kind of demonstration, is not leading everyone astray. Please do not misunderstand.

I think the best thing to do is to remove the primary constructor, because it doesn't seem to help much beyond simplifying attribute assignment

[andreinitescu]

I wish that the primary constructor syntax wasn't identical to the record syntax, for two reasons:

Identical syntax of record, but it's a class and it actually works in an a very different way

class Person(string name);

record Person(string Name);

The class above will compile with only a warning, saying name is unused.

But in a class, a primary constructor with no body does not actually do anything at run-time. It does not generate auto implemented public properties like in a record.

So why would I want a constructor which does nothing? A primary constructor is still a constructor. Why does the primary constructor syntax allows me now to write constructors without a body? It seems to me like with a class primary constructor with no body, I'm now able to write something meaningless like:

class Person 
{
     public Person(string name);   
}

Is there a reason why properties are not automatically implemented for class too? Not only it will be on par with record, but it will also make body-less primary constructor for classes make more sense.

The primary constructor is a great new feature and I can see scenarios where it will help a lot with making the code more clear and explicit.
But my feeling is it will be a bit confusing for some junior C# developers.

Dreaming of record-like auto implemented properties in class

Another reason is that I so wished I could someday be able to have class implemented with the great succinctness of record:

class Person(string Name);

Similar to a record, the above code would make the class have an automatically generated public property public Name {get; set; }. But in contrast to a record, it would not get anything else auto generated (no equality, etc.).

Why not just use a record instead?

A record can do a lot more than it's needed sometimes. For example, everyone recommends using records for DTOs (Data Transfer Objects). But why would I need equality for example in DTOs?

[HeinziAT]

my suggestion would be to disallow body-less primary constructor in class

I see your point. Are you sure that would be worth it? The current warning (according to SharpLab) is

warning CS8907: Parameter 'name' is unread. Did you forget to use it to initialize the property with that name?

which seems pretty clear and helpful (enough) to me.

Unrelated to this: Additionally, in the future, have a way to specify you want public properties auto-generated, like for record, by some new parameter modifier:

Indeed. There have also been multiple requests in this feedback item to have a modifier for read-only parameters, so I do expect some extensions here in future versions.

[HeinziAT]

Many developers use record without the need of equality for example, and end up with a lot of bloated classes only because a record feels great to both write and read.

Agreed, but is the (binary file) bloat really significant? I fully agree that it will be nice when Primary Constructors for classes support auto-generation of properties, but, currently, I would not avoid record classes where they make code easier to read just because of binary file size micro-optimization.

[davidroth]

I'm sorry, I disagree. Apps can have a ton of DTOs. But the DTOs was just an example.

Agreed, but is the (binary file) bloat really significant? I fully agree that it will be nice when Primary Constructors for classes support auto-generation of properties, but, currently, I would not avoid record classes where they make code easier to read just because of binary file size micro-optimization.

Just did a quick test.

Generated an empty console project with 1.000 records, each having 5 properties.
Then i generated an empty console project with 1.000 classes, each having 5 properties.

Results:

• 1.000 records a 6 properties: 2.066 KB
• 1.000 classes a 6 properties: 666 KB

So there is a measurable difference but even when having a huge amount of DTOS (1.000 in this example), the difference is not too big to be a concern IMHO.

[En3Tho]

I don't really understand the bloat argument. You still have GetHashCode/Equals as instance members. It's not like records somehow give you hundeds of new members which pollut intellisense. It's not like records are visually bloated either. And for binary size people rather would go with AOT anyway.

Also, the feature you request is perfectly implementable with current C# features: analyzers and source generators. Just write a partial class with primary ctor, splat an attribute on it for property generation and voila.

And if you want to disallow primary ctors w/o parameters for your own/team use then just write an analyzer.

[HaloFour]

Identical syntax of record

Records without primary constructors already share all of the same syntax with classes. It is the record keyword that is the differentiator, not a primary constructor.

but it's a class and it actually works in an a very different way

Records synthesize additional opinionated members. This was already the case.

But in a class, a primary constructor with no body does not actually do anything at run-time.

The primary constructor allows the parameters to be captured and used in other members.

Is there a reason why properties are not automatically implemented for class too?

Normal classes are not value objects or DTOs. Having the constructor affect the API surface of the type to expose those values would not be desirable in many of the scenarios in which primary constructors would be useful, e.g. accidentally exposing the dependencies of the class.

[TrubbleAC]

Not 100% sure this applies to primary constructors or is a more general thing, but is there any thoughts on allowing capture of this for initializers when a primary constructor is present?

I.e., something like the following:

public class ClassA(int x)
{
    private ClassB InstanceB { get; } = new(this, x); // Currently invalid as `this` is not available in current context.
    // ...
}

public class ClassB(ClassA instance, int x)
{
    private int X { get; } = x;
    private ClassA InstanceA { get; } = instance;
    // ...
}

From what I can see, if I want to use this at all, I have to have an regular constructor and cannot use a primary constructor (or at the very least, I must reference the primary constructor which in my mind defeats the purpose of having the primary constructor in the first place for this use case).

My understanding is that I'd instead have to use an regular constructor in the following manner:

public class ClassA // Cannot declare primary constructor as it would conflict with regular constructor.
{
    public ClassX(int x) // Same parameters as previous primary constructor from first example.
    {
        InstanceB = new(this, x);
    }

    private ClassB InstanceB { get; init; }
    // ...
}

public class ClassB(ClassA instance, int x)
{
    private int X { get; } = x;
    private ClassA InstanceA { get; } = instance;
    // ...
}

[KifoPL]

After playing with this new feature, I found a place that could potentially get some improvement.

When I mix primary constructor with required properties, even though the property is always set in the primary constructor, this code doesn't compile:

var test = new Test("John Doe"); // [CS9035] Required member 'Test.Name' must be set in the object initializer or attribute constructor.

public class Test(string name)
{
    public required string Name { get; init; } = name;
}

I understand that since Name is supplied in the primary constructor it doesn't need the required keyword, however I would expect that the analyzer would hint (or warn) that the required keyword is redundant. Because now the class is written in a wrong way, but the consumer of the class gets errors instead of the class itself.

[Richiban]

I don't think this has anything to do with primary constructors; the issue is the same when mixing required properties with regular constructors.

As an aside, I would agree that giving a required property an initialiser should probably result in a warning (although SetsRequiredMembers might make this more complex).

[DavidArno]

@Richiban,

Whilst the same problem exists with mixing ordinary constructors and required properties, at least there is the [SetsRequiredMembers] work-around to suppress CS9035 in that case. That attribute cannot be applied to the type though so there's no way to apply it to a primary constructor.

[HaloFour]

Syntax to support attributes on primary constructors has been accepted (method target), but I don't know that it has been implemented yet:

https://github.com/dotnet/csharplang/blob/main/proposals/primary-constructors.md#attributes-targeting-primary-constructors

[hughesjs]

I really don't like this feature. I don't like it for records either. I think there should be precisely one way to declare a property in your class otherwise it just becomes confusing. You need to check for proper properties, and then you also now need to check for a primary constructor. For the sake of tersity, that's just not worth it imho.

[Xyncgas]

Happy to see this absorbed from F#, if I have to create a new constructor I have to call the primary constructor in the end to create that object, though I wish F# to just let me have functions of the same name to be automatically converted to one single function with multiple overloads I doubt I should talk about that language in C# discussion

[Rubenisme]

Can someone tell us how we should find the primary constructor with reflection?
We have a:
typeof(T).GetConstructors()

Will we also get a GetPrimaryConstructor method? Or maybe better a bool property indicating it's the primary constructor?

[DavidArno]

If you use the captured parameters in a way that does not create compiler-generated fields, you can just replace the primary constructor with a "regular" constructor at any time and get exactly the same IL.

If the parameter doesn't result in a field (according to the current implementation of "captures"), then the parameter isn't a captured parameter. It's just an ordinary parameter.

Also, your statement that "you get exactly the same IL" is not true. It's subtlety different as the base constructor is called at different points.

If you use the captured parameters in a way that creates compiler-generated fields, you can't get the same IL with "regular" C# code, since the compiler-generated fields have "special" names. Those fields, however, do have the CompilerGeneratedAttribute added to them.

This also isn't correct. You get the same [CompilerGenerated] annotated "unspeakable" fields for auto properties in types without a PC.

[HeinziAT]

@DavidArno

If the parameter doesn't result in a field (according to the current implementation of "captures"), then the parameter isn't a captured parameter. It's just an ordinary parameter.

You're right, I should have used the phrase "PC parameters" instead.

Also, your statement that "you get exactly the same IL" is not true. It's subtlety different as the base constructor is called at different points.

Good observation. Does this allow you to create an example where a PC cannot be replaced by a regular constructor without breaking backwards compatibility? (I couldn't find one, but that doesn't mean that there isn't one.)

You get the same [CompilerGenerated] annotated "unspeakable" fields for auto properties in types without a PC.

Not exactly the same: This code example

public class A(int i) {
    public void M() {
        Console.WriteLine(i);
    }
}

will create a backing field <i>P, not <i>k__BackingField. I don't think you can replicate that with auto-properties.

[DavidArno]

Good point. The field names do differ depending on whether the capture occurs via a property backing field or a "parameter capture" field. I suspect though, that this really is in the realms of implementation details and would be a risky thing indeed to rely on matching such names via reflection.

As @Rubenisme says, this request came about due to a misunderstanding about whether a PC needed to be called or not. So it sounds like you are right: there's currently no real use-case for needing to determine if a constructor is a primary constructor or not and the team can safely focus on readonly support as a priority 😃

[Xyncgas]

If everyone is using term 'PrimaryConstructor' maybe we can advance the .NET core lib to use it as the name of the method to get the primary constructor in reflection

[HaloFour]

The compiler doesn't emit metadata to identify the primary constructor. You might be able to guess based on implementation details, sometimes, but that depends on what the class does internally with the parameters and can change. As mentioned, it's intentional that the primary constructor does not stand out or get treated specially by consuming code. It's a goal to be able to convert to/from using a primary constructor without affecting the public surface of the class.

[sliekens]

I updated my code to C# 12 and primary constructors, and I found what I think is a bug: I get a CS9110 about the use of a constructor parameter with ref-like inside an instance method, but the method is itself a member of a ref struct.

The error goes away when I uncomment line 3, which makes me believe this is a bug.

internal ref struct CharSpanSplitter(ReadOnlySpan<char> value, char separator)
{
    // private ReadOnlySpan<char> value = value;

    public bool MoveNext(out ReadOnlySpan<char> result)
    {
        // CS9110: Cannot use primary constructor parameter 'value' that has ref-like type inside an instance member
        if (value == ReadOnlySpan<char>.Empty)
        {
            result = ReadOnlySpan<char>.Empty;
            return false;
        }

        // CS9110: Cannot use primary constructor parameter 'value' that has ref-like type inside an instance member
        var index = value.IndexOf(separator);
        if (index == -1)
        {
            // CS9110: Cannot use primary constructor parameter 'value' that has ref-like type inside an instance member
            result = value;
            // CS9110: Cannot use primary constructor parameter 'value' that has ref-like type inside an instance member
            value = ReadOnlySpan<char>.Empty;
            return true;
        }

        // CS9110: Cannot use primary constructor parameter 'value' that has ref-like type inside an instance member
        result = value[..index];
        // CS9110: Cannot use primary constructor parameter 'value' that has ref-like type inside an instance member
        value = value[(index + 1)..];
        return true;
    }
}

[Xyncgas]

I have noticed member methods returning byref such as Span in fsharp can not be inlined, otherwise mentions referencing internal / private, don't know if that's related to it

[CyrusNajmabadi]

@sliekens

As the specification says:

Capturing is not allowed for parameters that have ref-like type, and capturing is not allowed for ref, in or out parameters. This is similar to a limitation for capturing in lambdas.

https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/primary-constructors.md#semantics

[mmmasent]

Not sure if this the correct place to ask/provide this, but is there a mechanism for doing null checking on parameters to a primary constructor? In my DI setups, I like to ensure the properties are in fact set. Any way we can utilize [NotNull] or some other attribute to do that internally?

[HaloFour]

There's nothing built-in that would do the null check. There's discussions around adding syntax for a constructor body and/or post-initialization method where argument validation could occur. Otherwise, you could write code that explicitly captures the primary constructor argument as a field and perform the check in an initializer:

public class Foo(string bar) {
    private string bar = bar != null ? bar : throw ArgumentNullException("bar");
}

A source generator could also key off of primary constructor parameters annotated with NotNullAttribute and emit that same code. That's probably as close to automatic validation as you'll get currently, though.

[CyrusNajmabadi]

Or the preferred form:

private string bar = bar ?? throw ArgumentNullException("bar");

:-)

[saint4eva]

Use required keyword on your properties also

[dersia]

we are using primary constructors for records and classes for a while now and we don't want to miss it. the only issue that we are having, is that it is messing up with the naming guidelines. for example we have the guideline, that private fields should be prefixed with _ or that public properties should be Pascal Case, where as parameters/arguments of a method should be came Case. the issue that we are seeing are not during development, since intellisense is doing the "right" thing here, but during code reviews, where the code reviewer is confused that there is a symbol the is corresponding to guidelines a parameter symbol name, but it is not defined in the arguments list of the method that he is reviewing. so it takes time to understand, that this come from the primary constructor.

I would love to have attributes to influence how the arguments are used:

[Flags]
public enum NamingRules
{
    PascalCase,
    UnderscorePrefixed,
    // others
}

[PrimaryConstructorNaming(PropertyNameRules = NamingRules.PascalCase, FieldNamingRules = NamingRules.CamelCase | NamingRules.UnderscroePrefixed)]
public class MyDTO([Property] foo, [Field] bar)
{
    public void FooBar()
    {
        Console.WriteLine($"{Foo}.{_bar}");
    }
}

of course this needs to be well designed, but this is our experience if PrimaryConstructors

I hope this feedback helps.

[HaloFour]

You could implement this today with a source generator that would inspect the custom attributes and emit a partial type with those members and the requested naming convention, using the primary constructor parameters to initialize them.

[ZzZombo]

It's odd to leave PC w/o any body, for this reason numerous times we had to revert to using regular constructors in the past.

[dayo05]

Hi, In Kotlin language, it has similar feature:

class SomeClass(val x: Int, val y: Int) {
}

This might equivent with C#'s:

class SomeClass(int x, int y) {
}

In Kotlin, I can get primary constructor with this via Reflection:
SomeClass::class.primaryConstructor
Is there any similar way to get primary constructor in C#?

[dayo05]

This is the part of my personal project code:

public abstract class RuleInstance
{
    public abstract AbstractTimeRule /* delegate */ Process { get; }
}
public class DayOfWeekRule(DayOfWeek dow) : RuleInstance
{
    public override AbstractTimeRule Process => range =>
    {
/* code */
    };
}
/* Code in static class */
private static Dictionary<string, Func<JsonObject, RuleInstance>> Redirect = new();
public static RuleInstance ParseRule(JsonObject node)
{
    var id = node["Id"]!.GetValue<string>();
    return Redirect[id](node);
}

Basically the RuleInstance instance will constructed from JSON data with fully customized logic(UTF8JsonReader). The Redirect Dictionary contains bulk of methods convert JSON data into Instance and there are another logic selects method to execute.

It works and it seems fine. But I thought it can be better to parse exact one constructor and initialize with reflection. This can avoid writing repeated extra JSON parsing code.

Then the next question is how to select the constructor. This can easily achieved using Attribute. But the purpose matches the word primary. Integrating this syntax makes exact one constructor can selected by each class without extra code and also can make code more readable.

[HeinziAT]

I think the strategy employed by the System.Text.Json deseralizer would also fit nicely for your use case: (a) If there is only one constructor, use that one. (b) If there are multiple constructors, require one of them to have a specific attribute. Using the primary constructor as a tie-breaker for (b) seems strange: It assumes that the constructor chosen as the primary constructor is also the best choice for your (custom) JSON deserialization. However, the decision for the former is usually made from an "implementation detail" POV, whereas the decision for the latter needs to be made from a "business rule" POV.

[dayo05]

I assume as if the value on primary constructor same then two object are same and no side-effect exists.(Extra values are considered as optional or can be calculated by value inside ctor)
Also I know that it can be resolved by business rule. But IMO it will be better if there no need to verify if rule matched.

[colejohnson66]

There is an argument to be had about not being able to put attributes on the primary constructors:

// attribute is on the class, not the constructor
[MySourceGeneratorAttribute]
public class MyClass(int value)
{
    // ...
}

Perhaps [ctor: XAttribute] could be added?

[CyrusNajmabadi]

You can already add an attribute on the constructor using this syntax: [method: XAttribute] class MyClass(...) { }