# C# Language Design Meeting for June 17th, 2024

## Agenda

- [`params` Span breaks](#params-span-breaks)
- [Overload resolution priority questions](#overload-resolution-priority-questions)
    - [Application error or warning on `override`s](#application-error-or-warning-on-overrides)
    - [Implicit interface implementation](#implicit-interface-implementation)
- [Inline arrays as `record struct`s](#inline-arrays-as-record-structs)

## Quote of the Day

- "I don't want to jinx it, but this is the last open question"

## Discussion

### `params` Span breaks

Champion Issue: https://github.com/dotnet/csharplang/issues/7700  
Issue: https://github.com/dotnet/roslyn/issues/73743

Today, we followed up from [last time](LDM-2024-06-12.md#params-span-breaks), 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.

#### Conclusion

Do not change the compiler. Improve the error reporting experience.

### Overload resolution priority questions

Champion issue: https://github.com/dotnet/csharplang/issues/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.

#### Application error or warning on `override`s

Following up from the [last time](LDM-2024-05-13.md#overload-resolution-priority-questions), 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.

##### Conclusion

It is an error to put `OverloadResolutionPriorityAttribute` in a location that would be ignored by the compiler, such as method overrides.

#### Implicit interface implementation

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 `modopt`s
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.

##### Conclusion

We will not inherit `OverloadResolutionPriorityAttribute` from interface definitions.

### Inline arrays as `record struct`s

Champion issue: https://github.com/dotnet/csharplang/issues/7431  
Issue: https://github.com/dotnet/roslyn/issues/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 struct`s
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.

#### Conclusion

Applying `InlineArrayAttribute` to a `record struct` will be an error.
