- "I'm also of many minds on this, maybe more than 2"
Champion issue: #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 structs 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:
- We could make overload resolution in expression trees in expression trees ignore
ref structs, as this proposal suggests. - We could more strongly enforce the restriction on
ref structs in expression trees, and error when one is used implicitly, like in these scenarios. - 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 structs can often work in Expressions 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.
Proposed change is rejected. We will make no changes to how overload resolution in expression trees occurs.
Champion issue: #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
ininstead ofas,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)ore1 (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.
No conclusion here today.