# C# Language Design Meeting for December 9th, 2024

## Agenda
- [First-class span open questions](#first-class-span-open-questions)
- [Simple Lambda Parameters](#simple-lambda-parameters)
- [Collection expression arguments](#collection-expression-arguments)

## Quote of the Day

- "Array covariance is like spice girls, no one admits to liking them but someone is buying the albums"

## Discussion

### First-class span open questions

Champion issue: https://github.com/dotnet/csharplang/issues/8714  
Spec diff: https://github.com/dotnet/csharplang/commit/7e964ef0ca8620eb4e7129396e867059d6c26be4#diff-e5dfbc21202c1a2f879f6221ecd9105efde1815d69cbe2db81189b1a667db328

First up today, we took a look at the specific proposed wording for our rule from [last time](LDM-2024-12-04.md#preferring-readonlyspant-over-spant-conversions).
We're happy with this direction, though the specific wording needs to be reworded: by the proposed rule, multiple bullets could be true at the same time in opposite
directions, leading to an ambiguity. The intent behind the rule, though is correct and agreed on. We continue to stand by our reasoning that `ReadOnlySpan` should
be preferred over `Span`, and the intent of these rules is to enable precisely that.

#### Conclusion

Direction is approved, modulo a bit of wordsmithing to remove ambiguities.

### Simple Lambda Parameters

Champion issue: https://github.com/dotnet/csharplang/issues/8637  
Open questions: https://github.com/dotnet/csharplang/blob/9cca9e78ac7c35af896bf4643a5c3cd2aef828b2/proposals/simple-lambda-parameters-with-modifiers.md#open-questions

Next, we took a look at a couple of open questions for simple lambda parameters. The first seemed reasonable; making the definition of `scoped` depend on whether
there's a default value for the parameter seems much worse to us than a minor breaking change that we've already made in other locations. However, the second question
is more thorny. After discussion, we realized that we don't have an intuition of what `params` and `scoped` will do in terms of overload resolution. Will it cause
overloads to be thrown out? Or will it only have an impact after an overload has been chosen, potentially issuing an error because the modifier can't be applied
to the parameter? We're not comfortable making a decision with an imprecise understanding of the consequences today. Therefore, we'll come back next time with a
complete understanding of the rules that are being proposed and figure out if we need to cut any modifiers at that point.

#### Conclusion

`scoped` break is approved in theory, but we'll come back next time to determine if we will include `scoped` and `params` in this work.

### Collection expression arguments

Champion issue: https://github.com/dotnet/csharplang/issues/8887  
Spec: https://github.com/dotnet/csharplang/blob/9cca9e78ac7c35af896bf4643a5c3cd2aef828b2/proposals/collection-expression-arguments.md

Finally, we took a look at a proposed extension to collection expressions, that will also be used for dictionary expressions. We didn't have enough time left to get
into specifics of the proposal; the proposed syntax, in particular, didn't resonate with a lot of the LDM. In particular, we think this may be too indirect of a
usage of `with`, as it's not really related to the current usage of `with` in the language. However, we think there's promise in the general idea, and want to move
forward with the idea. We'll work on syntax at a later point.

#### Conclusion

General feature is approved to move forward, with the specifics to be discussed in the coming months.
