Added: Notes from October 21st, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-10-21.md

Agenda

• Primary Constructors
• Direct Parameter Constructors

[alrz]

Compared to primary constructors, direct parameters aren't that interesting. You still need to write all member declarations. While the latter can be accomplished cleanly by the former using the exact same amount of code (initialized member declarations), except that having members would be optional, which is in fact the case most of the time, unless you want a record which is separately available.

To me, direct parameters look a little unwieldy and make the code actually harder to read, especially if mixed with normal parameters. On the other hand, primary ctors are already a familiar syntax and won't add a new concept to the language.

A few features discussed are already covered by records which surprised me that they are brought up here. For instance, we're practically passed the casing problem because that only mattered for positional records which is already settled down. We don't need yet another mechanism to deal with parameter/member correspondence.

[HaloFour]

Agreed, to me primary constructors feel much more immediately useful, but perhaps that's because I'm used to Scala where I make frequent use of them. I feel that the concise syntax of primary constructors, with the type and name in one place, makes it very easy to see what each parameter is. I'll also argue that the syntax of primary constructors should be much easier to grok by C# developers both because they feel like lambda parameter lists and because records will have shipped with the same syntax. The direct parameter syntax is completely new, feels unnecessarily different and separates the type from the name which, IMO, will make it more difficult to read.

[orthoxerox]

I agree. I think that the "setting lots of properties" use case can be better served by required properties.

[YairHalberstadt]

My main case for primary constructor is not setting lots of properties, but setting lots of fields.

Must of my classes are either data classes or behaviour classes. Records already serve the use case of data classes, so we only need to consider behaviour classes.

These very rarely have injected properties. However, I make heavy use of DI and so there are a lot of injected fields.

For such use cases primary constructor are perfect, because they allow you to inject a new dependency by changing exactly one location.

Direct constructors do not really help me that much- Now I need to repeat the name in 2 locations instead of 3, which isn't that great a saving.

[YairHalberstadt]

Based on hearing @CyrusNajmabadi's explanation for the LDM's favoring of direct constructor parameters there are a number of issues at play here:

1. They want the feature to work well for both fields and properties.
2. If primary constructors are used they should ideally be consistent with positional records.

On the other hand the proposed approach provides limited benefit for both fields and properties. You still have to repeat the name in multiple locations, which isn't all that helpful. What we really want is having one, and exactly one, place where the member is defined.

I still think going for option primary constructors is the best approach. I would rather have a really good solution to DI, then have an awkward solution for everything. However I also have another idea - consider this spaghetti against the wall.

For consistency with records, the following generates public properties:

class A(int X, string Y){}

If I want to inject variables for use within the class, which are implicitly captured as needed, I declare them as variables:

class A(var int x, var string y)
{
    public override string ToString() => y + x; // used outside initialization, so capture x and y in fields.
}

It's a bit odd as till now var always replaced the type name, and now it goes before the type and just means: not a field or a property, but a local. But I think it could work.

[alrz]

Conclusions

Our conclusions today are that we should pursue #4024 in ernest, and come back to primary constructors with that in mind. Several members are not convinced that we need primary constructors in any form [..] Once we've ironed out the questions around member references as parameters, we can come back to primary constructors in general.

This is while primary constructors already have a syntax and should be "relatively" simpler to design and implement? (and understand!)

More importantly, primary constructors is more like a primitive construct, direct parameters are too specific to be usable at all outside their spec'ed semantics.

I think if your needs is different than what records generate (which seems to be argument here; records but not records)
You can build on top of primary constructors and use source generators for the rest

For instance I need to use custom equality, non-init props, specific casing, and possibly custom getters:

[SnowflakeRecord]
partial class C(int p);

[MgSam]

We believe, at least from our initial reactions, that this form would be easier to understand than accessibility modifiers on the parameters.

Don't any members of the LDT ever consider Microsoft's other highly-successful language, TypeScript? It's had parameter properties since v1, released 8 years ago (wow has it been that long already!). The similar feature there is widely used and appreciated in that language, I don't see why it would be confusing in C#.

class A {
    constructor(public foo: number) { }
}

[CyrusNajmabadi]

Don't any members of the LDT ever consider Microsoft's other highly-successful language, TypeScrip

Yes. We discussed this at length. And, as an fyi, I was a language designer for TypeScript, including when we added that feature.

[MgSam]

I know you were, that's why I like to bring it up. :)

[Richiban]

Several members are not convinced that we need primary constructors in any form, given that our goal is not around making regular class types have only one line.

I'm absolutely crushed that the team is still not sold on the idea of primary constructors. A little bit of me dies inside every time I have to write something like this:

public class OrdersController
{
	private readonly IUserContext _userContext;
	private readonly IOrderRepository _orderRepository;
	private readonly ICrsfTokenValidator _tokenValidator;
	private readonly IEncryptor _encryptor;

	public OrdersController(
		IUserContext userContext,
		IOrderRepository orderRepository,
		ICrsfTokenValidator tokenValidator,
		IEncryptor encryptor)
	{
		_userContext = userContext;
		_orderRepository = orderRepository;
		_tokenValidator = tokenValidator;
		_encryptor = encryptor;
	}

	// Methods here...
}

This constructor simply should not be necessary. I hate writing them and reading them but in current C# there's nothing you can do about it.

My only hope now is that required properties can step up to the plate; hopefully this will be allowed:

public class OrdersController
{
	public IUserContext UserContext { private get; required init; }
	public IOrderRepository OrderRepository { private get; required init; }
	public ICrsfTokenValidator TokenValidator { private get; required init; }
	public IEncryptor Encryptor { private get; required init; }

	// Methods here...
}

Where by making the properties init-required but by hiding the getters you accomplish sort of the same goal of writing the (what are effectively) private readonly fields only once and still having them unchangeable after the class is constructed.

It's not great; the syntax is still far too heavy, but at least it doesn't involve any repetition and I think the hiding space for bugs is significantly reduced.

[CyrusNajmabadi]

I'm absolutely crushed that the team is still not sold on the idea of primary constructors

I don't know where this is coming from. The idea of language design here is that we explore the space and consider lots of options and ideas here to get a sense of the pros/cons and what direction we might want to go in. That doesn't mean we're not sold. It means we don't want to put all our eggs into one basket without fully knowing if that is the best direction forward.

In the case of primary constructors, tehre are a lot of cases to think of, and lots of options that only solve a narrow slice of them. Exploring this space just helps us figure out how we ca navigate things here.

[Richiban]

I'm absolutely crushed that the team is still not sold on the idea of primary constructors

I don't know where this is coming from.

From these lines in the meeting notes:

Our conclusions today are that we should pursue [Direct Parameter Constructors] in ernest

and

Several members are not convinced that we need primary constructors in any form

[CyrusNajmabadi]

yes. i don't see how that matches what you're saying. Having some individuals not be convinced about the neccesity of something does not mean the team isn't sold on something.

Put another way: Pick any language feature we've ever done. You'll likely have several members not convinced that we need it. Note that the same holds true for TS and F# as well. Language design here is about exploring options and having everyone weigh in their opinions on what they think is important to try to see what may possibly produce an even better final result. A large part of that is ldm members raising concerns/doubts/other-scenarios/etc. so that solutions we produce are not overfit to only partial scenarios.

[Richiban]

Fair enough; thanks for the clarification. I'm glad the sentiment isn't as negative as I feared. Perhaps it's cultural (or just me!) but "Several members are not convinced that we need primary constructors in any form" sounded a bit to me like "the team doesn't really want to implement this feature".

👍

[CyrusNajmabadi]

As an example. I'm not convinced we need primary constructors in any form. I've raised my opinion here as i think it's valuable that we have really good justifications for this and that we are thinking through all these scenarios. However, like with many things in language design, i'm just one voice. With nearly all releases we'll do things that i personally disagree with. But that's why we have a language design group, and not just a single person who just unilaterally makes decisions. If we were all a homogeneous group of like-minded people, there really wouldn't be much point in us designing stuff together at all :)

[GabrielGreenwoodRg]

This is the agenda for the C# Language Design Meeting held on October 21, 2020. The topics discussed in the meeting were Primary Constructors and Direct Parameter Constructors.

Primary Constructors are a new feature in C# 9.0 that allow developers to define a constructor within a class definition using the 'init' keyword. This constructor can be used to set the initial values of properties in the class without having to define a separate constructor.

Direct Parameter Constructors are a proposed feature that would allow developers to specify the values of parameters directly in the constructor call, rather than having to define the values as separate variables and then pass them into the constructor. This feature would simplify code and make it easier to understand. The proposal is still in the early stages of discussion, and no decision has been made yet on whether to include it in a future version of C#.

[333fred]

@GabrielGreenwoodRg, is there a reason you're posting what looks like a chatgpt summary here?

[MgSam]

Perhaps ChatGPT has gained sentience and is going around the web summarizing random things now.