- "People just stopped coming in" "I stopped coming in on Mondays. Today" "is not a Monday!"
#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/outmodifiers, 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 requirereforoutat 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.
The proposed specification is approved as proposed. Both open questions are rejected.
In the second half of the meeting today, we went over the remainder of the params collections specification and open issues.
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.
Proposed metadata format is approved.
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 scopedness 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:
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
}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.
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.
We will validate required members against the constructor that is used to determine eligibility to be a params parameter at the declaration site.