C# Language Design Meeting for June 10th, 2024

Agenda

• ref structs implementing interfaces and in generics

Quote of the Day

• No particularly amusing quotes occurred today. Sorry.

Discussion

ref structs 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 structs; 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 structs 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 structs implementing interfaces 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 structs 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 structs implementing interface?

Conclusion

Rules for ref structs in generics are approved. Rules for ref structs 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.