I resisted primary constructors for a while. They felt like a shortcut that would cost me later. But after using them across several projects, I'm sold, with one important caveat. Here's what convinced me to switch, and the one pitfall you need to watch out for.

MilanJovanovic's platform  covers topics related to software development, technology trends, and coding tutorials. Through articles, tutorials, and code examples, MilanJovanovic offers insights into programming languages, development frameworks, and best practices in software engineering. Readers can learn about software design principles, development methodologies, and emerging technologies to enhance their coding skills and build high-quality software applications.

Milan Jovanović

C# 12 primary constructors can significantly reduce boilerplate in DI service classes by eliminating field declarations, constructor bodies, and assignments. The author shares their experience switching to primary constructors for ASP.NET Core services, explaining the key pitfall: parameters are captured as mutable variables, not readonly fields, meaning accidental reassignment compiles without warning. The recommended approach is to use primary constructors freely in DI service classes where accidental reassignment is unlikely, but fall back to traditional constructors for validation-heavy types, multiple constructor overloads, or classes with too many dependencies.

Why I Switched to Primary Constructors for DI in C#

Where I Use Them Most: DI Service Classes

Where I Still Use Traditional Constructors

I love Primary constructors they’re so much cleaner, this is a great article about why you should use them

In neovim I had with easy-dotnet suggestion to just this type of refactoring
Roslyn feature would that be?