LDM Notes for July 26th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-26.md

Agenda

• Primary constructor parameters and readonly

[ds5678]

In my opinion semi-auto properties are less controversial than primary constructors, and they were delayed to C# 13, so primary constructors should be too. A little more time to "do it right" would be probably be best for the future of the language.

Alternatively, interceptors have set a precedent for adding experimental features to the language. Since most of the implementation work has already been done on primary constructors, they could be given a similar treatment in C# 12 and promoted to a full feature in C# 13, perhaps with some breaking changes based on feedback from the C# 12 version.

[HaloFour]

In my opinion semi-auto properties are less controversial than primary constructors

It sounds like a decision regarding the path forward with primary constructors will be settled by early next week. If the team feels that there isn't enough time to implement that decision then the feature would definitely be delayed. The decision isn't going to be made under the assumption that the feature needs to ship in the C# 12 timeframe, but I disagree that the design is that controversial here.

Semi-auto properties have the additional problem in that in order to implement them such that the field keyword and value keyword behave similarly, a mechanism to deal with minor breaking changes in the language needs to be handled. Treating those keywords similarly is something that the language team desires given that they are expected to be used right next to each other and the difference in semantics would be pretty glaring. That is the major reason that they have been delayed.

[CyrusNajmabadi]

In my opinion semi-auto properties are less controversial than primary constructors, and they were delayed to C# 13, so primary constructors should be too.

The 'field ' feature wasn't delayed because it is controversial. It has been delayed because the current design has a soft dependency on a feature we want to ship early in c# 13. So it made some sense to align on that.

Primary constructors had consensus that we want to do a tweak here. There are just a couple of options were want to decide between. No need for a delay due to that.

[Richiban]

WRT primary constructor parameters, did you consider going with Option 4 (readonly by default) for v12 as a possibly interim measure, since it can always be relaxed in a future version of C#?

For example, C#12 could have primary constructor parameters that are readonly, then (based on wider community feedback) C#13 could allow you to mutate them during initialisation. It's a way of being able to defer that decision without having to delay the whole feature.

[CyrusNajmabadi]

Readonly to non-readonly is a breaking change (and vice versa). It changes the meaning of how variables are actually used. See the conversation going on in the primary constructors thread for more details: #7377 (reply in thread)

[qrli]

👍 I'm OK with either option 2 or 3.

For 2: The primary use case would be dependency injection where no validation is necessary. For other cases, if value clamping or value fallback is necessary, we can fall back to a normal field.

For 3: It seems to be better at both sides. It provides mutability inside the constructor (for value clamping/fallback), while read-only elsewhere (where I'm really concerned with). In addition, it is consistent with records. Perfect.