# 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/simple-lambda-parameters-with-modifiers.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/7700

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.
