# C# Language Design Meeting for September 1st, 2021

## Agenda

1. [Lambda expression conversions to `Delegate`](#lambda-expression-conversions-to-delegate)
2. [C# 11 Initialization Triage](#c-11-initialization-triage)
    1. [Required properties](#required-properties)
    2. [Primary constructors](#primary-constructors)
    3. [Immutable collection initializers](#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](LDM-2021-08-23.md#better-function-member-now-ambiguous-in-some-cases). 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](LDM-2021-08-30.md), 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.
