# C# Language Design Meeting for January 15th, 2025

## Agenda

- [`fieldof`](#fieldof)
- [Simple lambda parameters](#simple-lambda-parameters)
- [Interpolated string handler method names](#interpolated-string-handler-method-names)

## Quote of the Day

- "First mute of 2025. Made it to 1/15. New record."

## Discussion

### `fieldof`

Champion 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:

```cs
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.

#### Conclusion

This proposal will go into the working set to be actively considered.

### Simple lambda parameters

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](../2024/LDM-2024-12-09.md#simple-lambda-parameters) 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.

#### Conclusion

We allow `scoped` to be used without an explicit type. We forbid `params` without an explicit type.

### Interpolated string handler method names

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.
