meetings/2026/LDM-2026-01-12.md
i?"partial and ref modifiersChampion issue: https://github.com/dotnet/csharplang/issues/9804
Spec: https://github.com/dotnet/csharplang/blob/c4ec6fb60c2e174b1abb6c019f22bb15b9b13f6c/proposals/relaxed-partial-ref-ordering.md
We are in favor of this. Historical reasons for this restriction were both implementation driven and a more conservative approach to breaking changes. We want to move forward, into the working set.
Champion issue: https://github.com/dotnet/csharplang/issues/9848
Spec: https://github.com/dotnet/csharplang/blob/c4ec6fb60c2e174b1abb6c019f22bb15b9b13f6c/proposals/deconstruction-in-lambda-parameters.md
More skepticism on this one. There are some concerns about the readability of the syntax, particularly in single-parameter cases, and an overall question as to whether this piece of syntactical sugar is worth it, particularly since several members think that it would never be able to apply to non-lambdas (given that parameter names matter more there). We'll put it in the working set to take a closer look though, and make a more comprehensive determination.
Champion issue: https://github.com/dotnet/csharplang/issues/9633
Spec: https://github.com/dotnet/csharplang/blob/c4ec6fb60c2e174b1abb6c019f22bb15b9b13f6c/proposals/unsigned-sizeof.md
We think that this proposal is probably too much work for the benefits that it would bring; adding any new conversion comes with
considering breaking changes, and we're not sure it's worth that level of effort for just sizeof. However, we do think that there
could be an interesting expansion that would potentially pay for itself in a broader "non-negative integer" feature, that could apply
not just to sizeof, but also collection count/length. We already special case these a bit in pattern matching, where the pattern
arr switch { [_, ..] or { Length: 0 } => "" } is considered exhaustive, even though Length: < 0 is not matched on. If we can square
that with sizeof, and expand it to the broader language, then we may be more amenable to that. For now, though, this will go into
the backlog.
break and continue StatementsChampion issue: https://github.com/dotnet/csharplang/issues/9875
Spec: https://github.com/dotnet/csharplang/blob/c4ec6fb60c2e174b1abb6c019f22bb15b9b13f6c/proposals/labeled-break-continue.md
The LDM is unsure overall here, but wants to delve deeper in a full session to hash it out. We'll put it in the working set for now.
Champion issue: https://github.com/dotnet/csharplang/issues/9921
Spec: https://github.com/dotnet/csharplang/pull/9920
We like it. Into the working set.
Champion issue: https://github.com/dotnet/csharplang/issues/9754
Spec: https://github.com/dotnet/csharplang/blob/c4ec6fb60c2e174b1abb6c019f22bb15b9b13f6c/proposals/immediately-enumerated-collection-expressions.md
This was delayed so we could assess feedback from collection expressions on where natural types are desired. The areas that we've heard are addressed by this proposal, so we're ready to move forward and we'll put it into the working set. This proposal also subsumes https://github.com/dotnet/csharplang/issues/9739, so that will be closed as a duplicate.
Champion issue: https://github.com/dotnet/csharplang/issues/9923
Spec: https://github.com/dotnet/csharplang/pull/9922
One big question is how this behaves in the face of spread cases. The goal of the proposal is to avoid extra copies, but that copy
seems like it may be inevitable in such cases, since the compiler can't know how big of an array to allocate the likelihood that it
will guess correctly is low. After some discussion, we've settled on a different goal: make ReadOnlyMemory<T> work with collection
expressions. We'll investigate approaches for doing so, and if other types can come along for the ride, all the better, but we won't
have it as the overriding goal unless we can see good evidence that the type is widely used and supported. This issue will go on the
backlog until that happens.