Primary Constructors in C# 12 Explained!

Assigning the primary constructor to a fullset property results in having two fields in your class - one for the field and one for the primary constructor. Unfortunately, we can't make the generated field as read-only in the primary constructor. If we assign parameter to a property it might cause the object to consume double the memory or at least bug prone as we have to make sure which one is used in the class. If you bypass the primary constructor to the parent, the field will exist in derived class too! This feature can be quite confusing, and I wish there was an option to disable it completely to prevent our team from using it.

I find this kind of code disgusting. There is too much happening under the hood and you have to have more knowledge about the feature / flow of the code. Your default constructor gives us a scope and a 'main line' about the executing of the code and how it all connects together.

I know it's demo code, but.... WHY DOES YOUR PERSON HAVE A PRINTNAME() METHOD?! And then.... WHY ARE YOU INJECTING A LOGGER INTO IT?! These dependencies are so wrong!

To be honest looks neat, but when you replaced the MonkeysViewModel with the primary constructor we don't have any longer the whole code on the file in front of us, we need to scroll sideways, which for me is not super. We could get some line breaks and still be fine, I would say.

Looks like you missed to say that primary constructor creates private field with the same name as its parameter. Nice video thou. Thanks.

it only makes the code harder to understand. everything is scattered around the class.

O M G what a shit... almost like using without {} brackets but even worse in terms of readability. Hope this "feature" die by no usage.

I can see that it's borrowed from kotlin and I love it

The savings are not worth it the insane scoping rules. i'd rather have them port the records primary constructors to classes so at least they can be used to declare properties

what about the underscore convention for variables, specially private ones? defining a area of variables with _ to me helps a lot!

does it work with mapster's MapToConstructor?

C# were perfect around C# 8 or 7. Now it's completely bloated. This is exactly how it became bloated. "We want to make programmers write less lines" so now you have weird symbols and strange syntax everywhere that's nobody understands, it's less readable, it's not helping anything really, yeah it took 1 sec less to write my class hurray, now it's difficult to understand what's going on. Please stop it.

I'm indecisive whether I like it and will use it, or not. What bothers me mostly is the different behavior to records for the same syntax.

This primary constructor sucks...

1. Most people prefer private field names with underscores. How stupid it would be to have smth like this: Person(string _name)...

2. And what about records? Their primary constructors behave differently. The parameters are not private fields but properties with "get" and "init" modifiers.
It would make more sense to have the same implementation in both cases then

I love these new features. If I'm hopeful my employer will adopt C# 12 by 2030 😂😂

This is pretty cool, James! But… How does this work with DI? The DI container had to have been getting the class instantiation signature from the constructor. Does this require a newer version of the container?

dude you gonna loooooove typescript

Thanks

hmm... interesting feature, but where to check constructor params (for null, as example) and throw exceptions if necessary? isn't that common practice to do such in constructors?

Useful

So first they introduced multiple property styles which was undesirable and stupid (as if anyone would want their language to facilitate mixing different styles that do the exact same thing, we don't mix formatting styles, we didn't need this). They must have figured you still had too much opportunity to focus on your coding logic. You would rather use a part of your brain to figure out different constructor styles as well, would you not? Let's clutter the class declaration some more, just the class name, a base class and a number of interfaces is way too easy, let's throw in some arguments for no ffin' benefit at all. Way to go C# designers.

like it!

Nice video James. For someone who's written C# for less than a year, this feature looks cool to me 😄. I'll try it out

I'd take robustness and readability over saving lines of code. But, if this makes (some) code more robust and readable, than I'm all for it. I'm not sure I'll personally use the feature because I see too many cases where it's detrimental (like giving up parameter checking) and I'd rather my code be consistent (versus some using primary constructors and some not).

I don't think allowing to create a Person with, say, a null name or a whitespace-only name, qualifies as robust. I'd prefer to throw an exception at construction rather than have some hard to track down condition where a bogus property caused a bug elsewhere in time and code.

I don't see myself having much use for the example around the logger, because usually that would just mean I have to pass more stuff that I might not need in most cases, so the use case feels a bit forced there. But I can definitely see the use case around having a primary constructor for myself when declaring small classes that are mostly used to shovel data between interfaces. Those will definitely look neater that way.

Neat. How nicely does it play when the [JsonConstructor] decorator is needed on one of the constructors? Also, how will this play with the Windows Community Toolkit?

C# is becoming more like Kotlin every day

Thank you so much James🌹. This is very helpful

If i have some logic in Constructor.

When will they finally add a constructor method, without a class name?

Does this mean we also get expanded generic constraints for constructor signatures?

Before you could only constrain a generic to have a default constructor with no params e.g. SomeClass<T> where T : new()

I see a benefit for structs and records where the parameters are the data being stored. But, what about constructors that have move than just assignments, and have calls to say a private initialisation method. That is not compatible with primary constructors right?

finally... no longer triplicated code when dependency injection... it's a dream come true. it's so frustrating, first you need them in the constructor, then inside the constructors bvody and secondy you need them as private readonly properties inside your case. triplicated code.

i was so close to switching all my classes to records just because it was so annoying but now it's finally coming to classes! now i'm happy <3

Coding is not about "saving lines of code" but about readability, so all sexy blink blink code shortcuts are simply making language less readable, and less bugproff, and imagine that right now you are start learning programming in 2023 and someone just give you that class, with primaru constructor but you need to learn at first what constructor is, and the question is why? Why you have used 'l' in seconda constructor? Any problems with the same property name? Offcourse and then try to described it to a person that that just start learning programming. Its simply a nightmare.

It would be great, if the c# team adds an option to make fields readonly by using the ReadOnly Keyword in the Primary Ctor

Its def a game changer but did you no about the = null trick on your interfaces I didnt until a more senior then myself pointed it out.