Skip to content

Latest commit

 

History

History
45 lines (30 loc) · 2.92 KB

LDM-2024-07-22.md

File metadata and controls

45 lines (30 loc) · 2.92 KB

C# Language Design Meeting for July 22n, 2024

Agenda

Quote of the Day

  • "A catscade of errors"

Discussion

Extensions

Champion issue: #5497
Spec change: #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: #7608
Related: Ref struct interfaces examples

Finally today, we are following up on a previous meeting where we asked for examples of using ref structs 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 structs, 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 structs implementing interfaces, and we will not warn on calling an interface member that has a DIM.