Primary Constructors (VS 17.6, .NET 8)

[YairHalberstadt]

@MadsTorgersen added a proposal for primary constructors yesterday: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/primary-constructors.md

I wanted to link the proposal to the issue for primary constructors, but I couldn't find any, so I thought I'd create this issue as a dumping ground for discussion.

NOTE:

I will interpret upvotes and downvotes as upvotes/downvotes on the proposal.

Meeting Notes:

• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-20.md#primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-27.md#readonly-modifiers-for-primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-08-31.md#ignored-directives-support
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-26.md#ungrouped
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-10-17.md#primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-02-15.md#open-questions-in-primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-02-22.md#primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-03.md#primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-08.md#primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-15.md#primary-constructors
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-26.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-31.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-09-25.md#primary-constructors

[YairHalberstadt]

My general opinion: I don't think it offers any real power over current solutions, and only really benefits brevity, at the cost of significant new rules and unfamiliar syntax. C# is a complex language as it is, and we should reserve additional complexity for where it can make a real difference.

I feel like records however will significantly change the way we write code, by encouraging greater use of small, immutable, data only objects.

As such my vote would go to records over primary constructors.

EDIT:

I partially retracted after some experience with scala. See my comment below

[HaloFour]

Apologize for brevity, on phone.

I like this, Scala has it. The primary constructor itself is just shorthand for the constructor with properties. You get the rest of the "record" behavior by making it a case class, which provides identity and deconstruction. Wrap that in an "enum" and you have DUs.

[YairHalberstadt]

@HaloFour

I think if this could be neatly packaged with records in a way that they felt like one unified feature, I might agree with you. At the moment, I'm not seeing that.

[HaloFour]

@YairHalberstadt

I could see it being helpful for DI, don't need to declare your dependencies three times (fields, parameters and assignments), just once. But aside that I probably agree. I'm ok with primary ctors as being just unopinionated shorthand, as long as it doesn't go down the rabbit hole of feature parity with normal ctors.

[orthoxerox]

I'm fine with PCs being a simple shorthand, with all their limitations, if we get a lightbulb operation that expands them into proper constructors.

@HaloFour the use of PCs for DI could be limited by their visibility. For example, your constructor takes three proper parameters and three injected dependencies. Your proper parameters must be validated and transformed by the constructor. You cannot extract your three dependencies into a primary constructor, because you would want it to be private.

[HaloFour]

@orthoxerox

You cannot extract your three dependencies into a primary constructor, because you would want it to be private.

I don't get why you'd need/want the PC to be private in that case, or why you'd need two constructors at all. I'd just have a single PC of the six parameters.

I'm also not saying that PCs would necessarily solve the issue for all DI-related construction, but they'd likely manage a good 90% or more.

[MgSam]

• This proposal seems completely incompatible with the current record proposal. And I disagree with the statement in the proposal saying this is more widely useful than records. I think this saves a little bit of boilerplate- records (and related features of auto-generating GetHashCode, Equals, ToString) can potentially save a ton of boilerplate in a lot of scenarios.
• I think the proposal is interesting but I hate all of the proposed extensions. Primary constructor bodies was the worst part of this feature when it was part of C# 6.0, it's still a bad idea today. If you need initialization logic make a real constructor!

[Richiban]

@HaloFour

I think if this could be neatly packaged with records in a way that they felt like one unified feature, I might agree with you. At the moment, I'm not seeing that.

I've said it before in other issues, but I'll say it again here. What do primary constructors have to do with records?

[YairHalberstadt]

@Richiban

Nothing intrinsically, but @HaloFour was suggesting a link, Mads indicated the syntaxes may clash, and they aim to solve similar pain points.

[HaloFour]

@Richiban

I've said it before in other issues, but I'll say it again here. What do primary constructors have to do with records?

With the way records have been proposed for C# they include symmetric construction and deconstruction as well as identify based on a specific set of properties. Primary constructors get you all of that in one parameter list given that the parameters are also properties and that list gives you an order in which those properties can be deconstructed.

C# records, as they have been proposed, are more like Scala case classes or F#'s single case unions, and both languages define the construct by how they are constructed.

case class Point(x: Int, y: Int)

val p = Point(1, 2)
val (x, y) = p

type Point = Point of X : int * Y : int

let p = Point(1, 2)
let x y = p

class Point(int x, int x);

var p = new Point(1, 2);
var (x, y) = p;

[brabebhin]

I really don't see the benefit for this. It lowers readability, and adds complexity.

If a class constructor gets more than 3,4 parameters you will usually want to refactor it to a builder or a group up the parameters into a "configuration" object, so not a lot is saved there. As for simple data classes, you can just have visual studio generate the constructors for you.

[orthoxerox]

@Richiban the syntaxes proposed for these two features are the same:

class Name(string value) {}

so if you use this syntax for primary constructors you need to think how records (who have value semantics) will look like.

[Richiban]

I really don't see the benefit for this. It lowers readability, and adds complexity.

If a class constructor gets more than 3,4 parameters you will usually want to refactor it to a builder or a group up the parameters into a "configuration" object, so not a lot is saved there. As for simple data classes, you can just have visual studio generate the constructors for you.

You mean it improves readability, surely?

I mean, it may well depend on one's coding style, but our codebase contains literally thousands of classes that look something like this:

internal class CosmosCustomerRepository : ICustomerRepository
{
	private readonly string _connectionString;
	private readonly string _collectionName;

	public CosmosCustomerRepository(string connectionString, string collectionName)
	{
		_connectionString = connectionString;
		_collectionName = collectionName;
	}

	public Customer Retrieve(CustomerId id)
	{
		// Create connection, execute query, return result
	}
}

Being able to reduce the above to:

internal class CosmosCustomerRepository(string connectionString, string collectionName) 
    : ICustomerRepository
{
	public Customer Retrieve(CustomerId id)
	{
		// Create connection, execute query, return result
	}
}

...is a big win for readability, if you ask me.

The constructors in the example above (of which there are many; a quick sample taken from our codebase of 30 classes shows that 22 of them (73%) had an explicit constructor defined and of those 21 (> 95%) did nothing other than set private readonly fields) are dumb, tedious, can be auto generated, are rarely read--normally skipped over--by humans (because they're usually so dumb) and are therefore a surprisingly common source of bugs.

Have you ever had to track down a bug that looked like this?

internal class SomeClass
{
	private readonly string _depA;
	private readonly string _depB;
	private readonly int _depC;

	public SomeClass(string depA, string depB, string depC)
	{
		_depA = depA;
		_depA = depA;
		_depC = depC;
	}

	// Methods here...
}

Or this?

internal class SomeOtherClass
{
	private readonly string _depA;
	private readonly string _depB;

	public SomeOtherClass(string depA, string depB)
	{
		_depA = depB;
		_depB = depA;
	}

	// Methods here...
}

I really truly believe that the majority of constructors look like this and they should not be written by humans.

Leaning on the IDE to generate them for you isn't really a solution because:

a) It won't stay in sync automatically. If you add a field you have to remember to add a corresponding constructor argument and assign it properly.
b) The developer still has to look at and read the auto-generated constructor. Sure, you could hide it in a region, but if the constructor is both auto-generated and then hidden then it really should be a language feature.