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

## Agenda

- [`ref struct`s implementing interfaces and in generics](#ref-structs-implementing-interfaces-and-in-generics)

## Quote of the Day

- No particularly amusing quotes occurred today. Sorry.

## Discussion

### `ref struct`s implementing interfaces and in generics

Champion Issue: https://github.com/dotnet/csharplang/issues/7608  
Proposal: https://github.com/dotnet/csharplang/blob/f2db071d1ccd4f69edf9c3186e13c4331630fa7b/proposals/ref-struct-interfaces.md

Today we went through the current version of the `ref struct` improvements specification to catch up LDM on all the implementation decisions that have been made
by team during development, as well as any wrinkles that the core libraries team ran into while absorbing the feature. Most of the changes were approved without issue;

* We confirmed that `allows` is the syntax we will go with for the feature, over `allow`.
* We discussed the implications of default interface members not being supported on `ref struct`s; it's an unfortunate limitation, but we can't think of any way around it.
  The boxing of the receiver is done by the runtime, so we can't try and allow it for specific DIMs that don't violate rules. We also don't see much of a use case for a DIM
  that doesn't call an instance member on the type immediately anyways.
* One of the marquee original intentions for `ref struct`s implementing interfaces was for `Span<T>` and `ReadOnlySpan<T>` to implement `IEnumerable<T>`. This would help
  solve a number of betterness issues with adding new APIs, but because `IEnumerable<T>.GetEnumerator()` returns an `IEnumerator<T>`, we can't implement it in an allocation-free
  manner. That would cause any `IEnumerable` API to become a performance trap for `Span<T>`, which is extremely undesirable.

Looking further at this last point, we realize that this means that we don't have any major use-cases for `ref struct`s implementing `interface`s at present. The core libraries
teams do not currently have plans to use the functionality; they do intend to make heavy use of `allows ref struct`, but this will mainly be on "transparent" types, such
as `Action` or `Func`. The implementation of these types don't require specialization based on functionality, but instead serve as abstractions for user code that may want to
abstract over `ref struct`s as well. Given that we don't have example use cases for interface implementation to validate our rules against, we are a bit concerned about
shipping the feature in release without the ability to ensure that we are actually shipping a useful feature; it would not be good to ship something that consumers eventually
come back and say is unusable because we missed some critical design flaw. Given this, we're currently considering holding back that half of the feature in preview until we have
scenarios to validate against. We'd like to hear from the community here as well; what are your use cases for `ref struct`s implementing `interface`?

#### Conclusion

Rules for `ref struct`s in generics are approved. Rules for `ref struct`s implementing interfaces generally look good, but need validation against real world scenarios before we
allow this part of the feature to ship in anything more than preview.
