Added LDM notes for February 21st, 2024

meetings/2024/LDM-2024-02-21.md

@@ -0,0 +1,101 @@
+# C# Language Design Meeting for February 21st, 2024
+
+## Agenda
+
+- [Declaration of ref/out parameters in lambdas without typename](#declaration-of-refout-parameters-in-lambdas-without-typename)
+- [`params` collections](#params-collections)
+    - [Metadata format](#metadata-format)
+    - [`params` and `scoped` across `override`s](#params-and-scoped-across-overrides)
+    - [`required` members and `params` parameters](#required-members-and-params-parameters)
+
+## Quote of the Day
+
+- "People just stopped coming in" "I stopped coming in on Mondays. Today" "is not a Monday!"
+
+## Discussions
+
+### Declaration of ref/out parameters in lambdas without typename
+
+https://github.com/dotnet/csharplang/issues/338  
+https://github.com/dotnet/csharplang/blob/main/proposals/ref-out-lambda-params.md
+
+We started today by looking at an Any Time proposal specification to address a common cliff: when using a delegate type with a modifier of any kind, users are required to spell out the parameter types
+of that lambda. This is a change that the LDM has long mentioned in passing, but has never actually gone through and specified. In addition to the main proposal, we also discussed few potential
+alternatives:
+
+* We could potentially infer the `ref`/`out` modifiers, rather than having the user restate them. We don't like this option; C# thinks that changes in calling convention are very important, to the point
+  that we require `ref` or `out` at callsites. We think this would be the same cliff, and that therefore it should require the modifiers be stated explicitly.
+* We could go further, and allow some lambda parameters to be fully stated, and others to be just names. We don't currently have any real driving use cases for such a feature though, and it would be
+  quite complex. It would also likely want to be designed at the same time as thinking about the partial type inference proposal.
+
+We therefore wish to move forward with this proposal. We turned to thinking about the open questions. For both of them, we think that there are some implementation complexities that, while not insurmountable,
+would be challenging. Given this, and the lack of requests for either feature, we think that we should simply say that neither attributes nor default parameter values will be supported without a fully-typed
+lambda, as it works in C# 12. We do note that the specese will need to be cleaned up a bit: _implicit_anonymous_function_parameter_ex_ isn't a great name to put in the spec, but that can be fixed up without
+blocking the feature.
+
+#### Conclusion
+
+The proposed specification is approved as proposed. Both open questions are rejected.
+
+### `params` collections
+
+https://github.com/dotnet/csharplang/issues/7913  
+
+In the second half of the meeting today, we went over the remainder of the `params` collections specification and open issues.
+
+#### Metadata format
+
+https://github.com/dotnet/csharplang/blob/9d12a983190ba5d25fb037a2566bb1e99d486c49/proposals/params-collections.md#metadata
+
+The `params` collections proposal suggests using a new attribute type to declare when a non-array type is `params`, in order to avoid potential interop issues with non-C# compilers. After looking at
+the proposal and the reasons for it, the LDM is fine with this approach. The attribute will need to go through the BCL's design review.
+
+##### Conclusion
+
+Proposed metadata format is approved.
+
+#### `params` and `scoped` across `override`s
+
+https://github.com/dotnet/csharplang/blob/9d12a983190ba5d25fb037a2566bb1e99d486c49/proposals/params-collections.md#consider-enforcing-scoped-or-params-across-overrides
+
+Next, we looked at a potential area of confusion: `scoped` across overrides can potentially be confusing because `params` can be inferred. Specifically, because `params` can be implicitly inferred, and
+it implicitly implies `scoped`, `scoped` can be inferred a way that it cannot be today. While there is no safety issue here, we are concerned about potential for user confusion. The `scope`dness here is
+very different than the existing meaning of `params` because unlike `params`, which has no effect inside the method body, `scoped` _does_ have an effect inside the method body; it changes where the
+parameter can be used or returned. Given this, we think that it would be best to require overrides to specify either `params` or `scoped` if they would have otherwise been required to do so. As an example
+of the proposed rules:
+
+```cs
+class Base
+{
+    internal virtual Span<int> M1(scoped Span<int> s1, params Span<int> s2) => throw null!;
+    internal virtual void M2(scoped Span<int> s1) => throw null!;
+    internal virtual void M3(params Span<int> s2) => throw null!;
+}
+
+class Derived : Base
+{
+    internal override Span<int> M1(Span<int> s1, // Today: error, missing `scoped` on override
+                                   Span<int> s2  // Proposed: error, missing `scoped` or `params`
+                                  ) => throw null!;
+    internal override void M2(Span<int> s1) => throw null!; // Today: no error
+    internal override void M3(Span<int> s2) => throw null!; // Proposed: no error
+}
+```
+
+##### Conclusion
+
+We will require explicitly stating `scoped` or `params` on override of a `params` parameter when a non-`params` parameter would be required to do so.
+
+#### `required` members and `params` parameters
+
+https://github.com/dotnet/csharplang/blob/9d12a983190ba5d25fb037a2566bb1e99d486c49/proposals/params-collections.md#should-presence-of-required-members-prevent-declaration-of-params-parameter
+
+Finally, we looked at an edge case of when a collection type has `required` members. We don't expect this to be commonly hit (or even hit at all outside the compiler test base), but we do want to consider
+it. Given that we have already mandated that `params` collections types must have an applicable parameterless constructor, we think this is appropriate to use for validation at the declaration point
+of such a parameter. The call site may end up using a different constructor due to the binding rules of `params` collections, but we don't think that it's necessary to try and validate this; the call site
+will do its own checking, and the pathological case of a collection type that can be used as a `params` parameter because it has a parameterless constructor with `SetsRequiredMembers` applied but the
+other constructors that would be used at the call site is not something we need to try and account for.
+
+##### Conclusion
+
+We will validate `required` members against the constructor that is used to determine eligibility to be a `params` parameter at the declaration site.

meetings/2024/README.md

@@ -61,15 +61,17 @@ All schedule items must have a public issue or checked-in proposal that can be l
 - Breaking change with immutable arrays and collection expressions on downlevel scenarios (https://github.com/dotnet/roslyn/issues/72170).  Cyrus + Chuck
 - Dictionary-expressions + Collection-expressions future: WG to go over our plans, and the initial design space (Cyrus)
 
+## C# Language Design Notes for 2024
+
 ### Wed Feb 21, 2024
 
-- Review: [Allow lambdas with parameter modifiers, but without parameter types](https://github.com/dotnet/csharplang/pull/7369) (Cyrus)
-- Review [metadata](https://github.com/dotnet/csharplang/blob/main/proposals/params-collections.md#metadata) section for"Params Collections". (Aleksey)
-- Open question: [`params` mismatches across inheritance](../../proposals/params-collections.md#consider-enforcing-scoped-or-params-across-overrides) (Fred, Aleksey)
-- Open question: [Should presence of required members prevent declaration of params parameter?](https://github.com/dotnet/csharplang/blob/main/proposals/params-collections.md#should-presence-of-required-members-prevent-declaration-of-params-parameter) (Aleksey)
+[C# Language Design Meeting for Feb 21st, 2024](https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-02-21.md)
 
-
-## C# Language Design Notes for 2024
+- Declaration of ref/out parameters in lambdas without typename
+- `params` collections
+    - Metadata format
+    - `params` and `scoped` across `override`s
+    - `required` members and `params` parameters
 
 ### Wed Feb 7, 2024