Syntactic sugar for primary constructors

[ghadzhigeorgiev]

Will be nice to allow something like

public class User (string Name) <= (ILogger<User> logger) : Person, IEmployee
{...}

or

public class User (string Name) : Person, IEmployee <= (ILogger<User> logger)
{...}

It will be just a syntactic sugar but will be easy on the eye and will reflect better the intention.

This should not prevent one from using also

public class User (string Name, IConfiguration config) <= (ILogger<User> logger) : Person, IEmployee
{...} 

or old way

public class User (string Name, IConfiguration config, ILogger<User> logger) : Person, IEmployee
{...} 

which will keep existing code compatible.

[HaloFour]

Why does this need language support? You can already very easily manage DI via constructor, properties or other forms of injection through the supported features of whatever IoC container you are using.

[jnm2]

And with required properties or primary constructors, DI just got a lot nicer.

[ghadzhigeorgiev]

It's cleaner, for example:

public class User (string Name, string Email, DateTime BirthDate) : Person, IEmployee <= (ILogger<User> logger, Ixxxx<yyy> zzz, etc... )
{...}

One can clearly see what's part of the class, what's inherited and what are the interfaces, and lastly, what class needs to be injected from outside.

Now compare to

public class User (string Name, string Email, DateTime BirthDate, ILogger<User> logger, Ixxxx<yyy> zzz, etc... ): Person, IEmployee
{...}

quickly becomes messy.

Behind the scenes, compiler will generate same code and also, if one prefers the other ways, they still be there.

[HaloFour]

You're asking for a language feature to satisfy a use case with dependency injection. Language features are ridiculously expensive. The feature has to demonstrate how it satisfies general purpose use cases. If it's extremely niche because it doesn't even fit the normal parameters of dependency injection, then it has less purpose. I will argue that declaring a type where some parameters are dependencies and some are data are not typical in dependency injection, so this syntax doesn't solve use cases.

[ghadzhigeorgiev]

I may said that incorrectly, but after all it comes to Syntactic sugar, as title says. C# is now full of them.

[HaloFour]

Not all syntax sugar is equal. Splitting up the parameters of a primary constructor doesn't make sense to me. Having a syntax which makes it appear as if a member has one signature when it really has a different signature is not appealing to me.

[ghadzhigeorgiev]

And that's cool. I can accept that as opinion and personal preference, that's why I'm expecting this not to break other ways.
I myself, still prefer to see immediately "what's part of the class, what's inherited and what are the interfaces, and lastly, what class needs to be injected from outside".

[HaloFour]

and lastly, what class needs to be injected from outside

IMO, the language already provides a way to declare that: constructor parameters and required properties