meetings/2022/LDM-2022-10-10.md
Today we wrapped up our triage of the working set. All of the remaining items are not in a working group.
https://github.com/dotnet/csharplang/issues/5783
We feel that there's about one design meeting's worth of open questions in this issue before we could reasonably let it be open for implementation, either from the compiler team or from the community, so we'll try to do that work at some point in the near future.
https://github.com/dotnet/csharplang/issues/6045
This one is fairly uncontroversial with little outstanding design work.
https://github.com/dotnet/csharplang/issues/6051
Work for this one is in progress, and later on in the meeting we talked about adding params support for this.
Now that we've gone through our working set, we've decided on the following working groups (listed in no particular order):
ref struct improvementsparams improvementsWe also decided on a set of norms for working groups to follow with respect to notes and keeping track of their progress: every working group
will add a folder under the meetings directory where they will put meeting notes. These notes will be anonymized, like LDM notes,
but are likely to be much rougher than dedicated LDM notes. We will not create dedicated discussions when posting these working group notes. Users
that want to comment on them can either comment on the issue for the group or create a discussion, as they choose. Working groups will each have
a leader, and that leader will be responsible for coordinating with the broader LDM on when things need to be brought back to the full group.
Some statistics on the groups:
params support for lambda default parametershttps://github.com/dotnet/csharplang/issues/6051
To round out today, we discussed whether we should broaden the lambda default parameter work to include support for params, which sticks out
a bit for not being supported in the proposal today. While we don't have a direct use case, we think that if we want to make this change, we
should make it now as it is a breaking change for inferred delegate type scenarios when inferring from a method that has a params parameter.
We don't think that waiting for a use case would change the semantic design strategy here, as it needs to be consistent with the work already
approved for default lambda parameters.
We will add support for params, which will flow through the type system in the same way that default parameters do.