# C# Language Design Meeting for July 22n, 2024

## Agenda

- [Extensions](#extensions)
- [Ref structs implementing interfaces](#ref-structs-implementing-interfaces)

## Quote of the Day

- "A catscade of errors"

## Discussion

### Extensions

Champion issue: https://github.com/dotnet/csharplang/issues/5497  
Spec change: https://github.com/dotnet/csharplang/pull/8305

We started today by looking at the latest proposed changes for extensions. There was no real pushback on the string-based encoding erasure form, but we did bring up some concerns that may need to be addressed:

* How will the format work for local functions?
* We don't think that function pointers are necessary to support right now; extensions already have limited interactions with pointer types in general. If we can come up with specific scenarios, we could look
  at them at that point.
* We talked briefly about simply upgrading the `Type` format to allow encoding type parameters. However, that runs into the issue that the extension types would not satisfy type constraints. Any solution that involves concrete
  `Type` instances would likely break reflection in some way.
* We also briefly discussed whether we need to invest in a way to shrink the amount of metadata we emit. For now, we don't think we need to. The concern with nullable was that every member across an entire project
  would implicitly get new attributes. We're nowhere near that level here.

Overall, the encoding format here is generally approved.

### Ref structs implementing interfaces

Champion issue: https://github.com/dotnet/csharplang/issues/7608  
Related: [Ref struct interfaces examples](LDM-2024-07-22-ref-struct-interface-examples.md)

Finally today, we are following up on a [previous meeting](LDM-2024-06-10.md#ref-structs-implementing-interfaces-and-in-generics) where we asked for examples of using `ref struct`s in interfaces that we could
use as validation that the feature was designed and working as we hoped. We received a number of examples, and we'd like to thank all the readers of these notes who responded. There were a few examples in particular
that proved especially helpful, and they're called out in the linked examples file. Given these examples, we're happy with the feature at this point, and are ready to ship it for C# 13. We then took another look
at the DIM scenario for `ref struct`s, and whether we should consider a warning at the call site. We don't think that this is generally beneficial; the consumer doesn't really have an option for avoiding it, and we
can't catch all instances where this would happen. Instead, we think the onus is on the person who is implementing an interface on a `ref struct`; if the `interface` is updated, the implementor needs to go
recompile with the new interface member and publish a new version.

#### Conclusion

We are comfortable with shipping `ref struct`s implementing interfaces, and we will not warn on calling an interface member that has a DIM.
