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

## Agenda

- [Ignoring `ref struct`s in `Expression`s](#ignoring-ref-structs-in-expressions)
- [Extensions](#extensions)

## Quote of the Day

- "I'm also of many minds on this, maybe more than 2"

## Discussion

### Ignoring `ref struct`s in `Expression`s

Champion issue: https://github.com/dotnet/csharplang/issues/8714  
Proposal: https://github.com/dotnet/csharplang/blob/1393601a2a4c45222f027983a248a08996d8ff05/meetings/working-groups/ref-improvements/ignore-overloads-in-expressions.md

Today, we looked at a proposal to change how overload resolution works in expression trees. This isn't a step we want to
take lightly; our previous positions here, such as for `params ReadOnlySpan`, has been to let them exist, and then error if they
couldn't be used. Unfortunately in this case, there's a very good chance that instead of being a compile-time error, it will end
up being a runtime error instead. This has happened in the past, but as we increase our usage of `ref struct`s in C#, it keeps
coming up; the latest example is first-class spans, which causes breaks in the EF query provider when unexpected versions of
query methods get called. There are three options:

1. We could make overload resolution in expression trees in expression trees ignore `ref struct`s, as this proposal suggests.
2. We could more strongly enforce the restriction on `ref struct`s in expression trees, and error when one is used implicitly,
   like in these scenarios.
3. Do nothing and have EF's query provider understand the new methods.

Of these options, the only one we're ok with is option 3. For option 1, it will break scenarios that work perfectly fine today;
indirect usage of `ref struct`s can often work in `Expression`s that are compiled on CoreCLR. For option 2, it will force all of
our users to update their code to handle the new breaking change. For 3, it does mean that some users who are on older versions of
EF will face runtime errors when they update to C# 14, but don't update their reference to EF. However, those users will face such
issues in general, not just because of increased `ref struct` issues. For example, EF is adding support for new types of joins,
expressed through new query methods, and older query providers cannot handle those new methods just as they cannot handle these
`ref struct` overloads. We do not think that it is burdensome to ask EF to handle these new overloads, and thus that is our plan.

#### Conclusion

Proposed change is rejected. We will make no changes to how overload resolution in expression trees occurs.

### Extensions

Champion issue: https://github.com/dotnet/csharplang/issues/8697  
Proposal: https://github.com/dotnet/csharplang/blob/dc2672a9fb93dc2c5d782b3c5600eea469a9c581/meetings/working-groups/extensions/extension-member-disambiguation.md

Finally today, we looked at a proposal for how we might introduce a generalized disambiguation syntax. While this is useful for
extensions, we think it may also be more generally useful, such as allowing calling default interface members from class members.
While LDM likes the general direction, there was a lot of mixed feedback on the specific syntax forms shown here. Two potential
alternative directions were brought up:

* Use `in` instead of `as`, `at`, or `@`. This may more clearly define that we are looking for a specific member as implemented
  _in_ a specific type.
* Change the paradigm to instead qualify the member, rather than the receiver. For example, `e.(MyExtension.Prop)` or 
  `e1 (MyExtension.+) e2`. This may better qualify that the member is being bound in a specific manner, rather than the receiver.

A number of LDT members liked this second direction, but it will introduce some challenges for things such as constructors, which
don't have a syntax that can be referred to after a `.` today. `MyExtension.new` is a possibility, but we'll have to consider more.
Ultimately, we didn't come to any conclusions today, and will revisit again in a future meeting.

#### Conclusion

No conclusion here today.
