meetings/2025/LDM-2025-01-15.md
fieldofChampion issue: https://github.com/dotnet/csharplang/issues/9031
Specification: https://github.com/dotnet/csharplang/blob/7bf02aafb8fc623b5d21075514440b7e9fd4d94c/proposals/fieldof.md
We started today by looking a proposal around backing field access outside of a property accessor. This scenario is being driven
primarily through a few early adopters of the field feature, and the scenarios are interesting enough that we think exploration
of the area is worth it. However, LDM is much more mixed on this specific solution; several members were unsure of how well fieldof
fit in with typeof and nameof, and felt that it was too specialized to this specific problem, and not obvious where it should
end. One other option we floated was the ability to specify both init and set, so a property could look like this:
public int Prop
{
get;
private init;
set => SetAndNotifyIfChanged(ref field, value);
}
There are definitely some issues to work out with such a proposal, but we like that it seems more generalizable and fits in better with property declarations today. We didn't conclude on this topic today, but will come back in a future LDM after exploring this second approach more.
This proposal will go into the working set to be actively considered.
Champion issue: https://github.com/dotnet/csharplang/issues/8637 Spec: https://github.com/dotnet/csharplang/blob/7bf02aafb8fc623b5d21075514440b7e9fd4d94c/proposals/simple-lambda-parameters-with-modifiers.md#open-questions
We picked this up from the last time simple lambda parameters came up, around
whether scoped or params should be allowed without a type. These modifiers are slightly different on their impact: params
can only impact the call site, while scoped impacts both the call site and the body of the lambda. We're ok with scoped, because
of that reason. However, we're not ok with params; it can never narrow overload resolution, and we'll have to do extra checks to
make sure that params is allowed with the type that is inferred. Rather than having that extra check and potential for confusion,
we think it's a better idea to simply disallow params without a type. If we ever hear from users that this would be useful, we can
revisit at that point.
We allow scoped to be used without an explicit type. We forbid params without an explicit type.
Champion issue: https://github.com/dotnet/csharplang/issues/9046
Specification: https://github.com/dotnet/csharplang/blob/a970d01597886d84d7498e1b6a9d8e8e8ebf02c1/proposals/interpolated-string-handler-method-names.md
Finally today, we started triage for some newer issues. For this one, we think that we need a full hour in LDM to debate the
approach and alternatives, but are interested in moving forward, so it will go into the Working Set milestone.