- "I don't want to jinx it, but this is the last open question"
Champion Issue: #7700
Issue: dotnet/roslyn#73743
Today, we followed up from last time, now that the LDM has had some time to consider options. To recap, we left the last meeting feeling that our best course of action would be to not attempt to mitigate this in the compiler, but instead document the breaking change. We still think this is the case; attempting to mitigate this, either by changing how the compiler binds for expression trees, or using some kind of attribute, will just lead to us eventually needing to figure out how to undo the change later if we ever are able to modernize expression trees. We do think we should invest a bit more in the error experience; having the compiler detect when such an overload is used in an expression tree and issue a specific diagnostic, and having the IDE offer to add an explicit array creation will go a long way to making the experience understandable. But ultimately, we will not be trying to ensure the code will compile exactly as is, unchanged.
Do not change the compiler. Improve the error reporting experience.
Champion issue: #7706
Spec: https://github.com/dotnet/csharplang/blob/a50814bc5d5dacc9bc9b45db4d29c97ce91d2f1c/proposals/overload-resolution-priority.md#open-questions
Next, we went through the 2 open questions in overload resolution priority.
Following up from the last time, we need to decide what do when a user puts an OverloadResolutionPriorityAttribute on an overriding
method. These attributes are always ignored on overrides, so while it isn't necessarily an error in and of itself, such an application has no effect. We don't necessarily think that there's a
specific future scenario we want to preserve here, but we still think that such an application is a sign of a user misunderstanding the feature. Given that, we want to hard error in scenarios
where a user applies an OverloadResolutionPriorityAttribute that will be ignored by the compiler.
It is an error to put OverloadResolutionPriorityAttribute in a location that would be ignored by the compiler, such as method overrides.
Next, we looked at a related open question: should we try and have implicit interface implementations inherit priorities automatically? We don't think this is a good idea; concrete methods can
actually implement multiple interface members, with potentially different priorities. How they implement various interfaces can also be quite complicated, especially in the presence of modopts
on interface members; the compiler sometimes needs to emit bridge methods that explicitly implement interface members and then forward to the class implementation, should those get the attribute
automatically as well? We think it's ultimately simpler and more understandable for everyone if we continue the existing C# precedent that non-signature components, such as parameter names, params,
and attributes, are not inherited by implementations.
We will not inherit OverloadResolutionPriorityAttribute from interface definitions.
Champion issue: #7431
Issue: dotnet/roslyn#73504
Finally today, we looked at an overlooked scenario from C# 12; applying InlineArrayAttribute to a record struct type. We never addressed this scenario, so we generate default codegen for record structs
that are actually inline arrays. This means that for all the code we generate, such as Equals, GetHashCode, and ToString, we don't do any enumeration of all the array elements. Instead, we just
look at the first element. While this is likely something that we could update the C# compiler to handle correctly, we also question the value of doing so; inline array types have very specific
requirements, and record struct doesn't bring a ton of advantages for them. There's not a potentially changing list of fields to keep up to date, as inline arrays can only have a single field.
Thus, we think the right solution is actually to just make it an error to apply InlineArrayAttribute on a record struct. If there is demand after making this change, we can always revisit at a later
date, but until then, we will leave this as an error.
Applying InlineArrayAttribute to a record struct will be an error.