C# Language Design Meeting for September 1st, 2021

Agenda

1. Lambda expression conversions to Delegate
2. C# 11 Initialization Triage
   1. Required properties
   2. Primary constructors
   3. Immutable collection initializers

Quote(s) of the Day

• Starting the meeting with 11 minutes of technical issues
• "In my next language, no users"
• "Has anyone made that companion book? Javascript, The Terrible Bits"
• "Do we actually want to do this feature because customers are asking for it, or do we just think it's interesting as an LDM?"

Discussion

Lambda expression conversions to Delegate

https://github.com/dotnet/csharplang/issues/5124

Today, we do not allow lambdas without a natural type to be convertible to Delegate or Expression. This can lead to niche but possible cases where adding type information to a lambda actually makes a method call ambiguous, where the typeless lambda was unambiguous. These cases, however, are both niche and usually fixable by adding a new, most-specific overload, as we discussed in the notes last week. Making a change here would also break APIs where the user has an instance method that takes a Delegate (often not defined in their code) and adds extension methods with strongly-typed delegates to add the necessary information for the compiler to bind their lambdas. This is a fairly common pattern when working with a Delegate API, and despite making the language more complex and having weird consequences for niche cases, we think that keeping the existing rule as it is the appropriate compromise to keep existing code working. While we don't think that we would have this complex of a rule if we were redesigning the language, we also think that we've hit the limit of breaking changes we'd want to take in this feature.

Conclusion

We'll keep the conversion rules as they are.

C# 11 Initialization Triage

Continuing from last meeting, we're triaging potential C# 11 features, this time specifically around initialization and records. The same disclaimer from last time applies: this is early triage. Please do not try to infer what will be in C# 11 or not from these notes. If we don't know the answer to that, these notes won't help you find it either 🙂.

The general list of initialization and record related topics is as follows:

1. Required properties
2. Final initializers
3. Factories
4. Primary constructors
5. Public init fields
6. Immutable collection initializers
7. Combined object and collection initializers
8. Nested properties in with-exprs
9. Event hookup in object initializers

Of these, we can subdivide them into a few sets of categories:

• Truly new features that enable a new type of expressiveness that doesn't exist today. This is 1, 2, 3, and 6.
• Features that build off of others, either in this list or already in the language. This is 4 and 5.
• Features that solve pain points in existing features. This is 7, 8, and 9.

Of these, there are a few that stand out as being features we're more interested in: required properties, primary constructors, and immutable collection initializers.

Required properties

https://github.com/dotnet/csharplang/issues/3630

We did a big design push on this a little under a year ago. We should revive the proposal, make the changes we talked about at the end of the last design review, and see what we think about it now.

Primary constructors

https://github.com/dotnet/csharplang/issues/2691

We've had a few designs for primary constructors over the years. C# 6 nearly shipped with one design, then we shipped records with a design, and now we need to think about how primary constructors will interact with record/class cross inheritance when we get to that. We really need to come back with a new proposal that looks at the past versions, and that may well be next year.

Immutable collection initializers

This is an idea we've been ruminating on as we designed the syntax for list patterns: we've given up on trying to make the correspondence principle work with the existing collection initializer syntax, but we could potentially make the principle work by design a new collection literal syntax, one that will work with immutable types as the current one does not. A smaller group will look at this and make a proposal for the space.