C# Language Design Meeting for June 18th, 2025

Agenda

• Iterators in lambdas
• Extensions

Quote of the Day

• "A manager isn't on the hook" "Oh they are, they're just on the hook for making sure someone else is on the hook"

Discussion

Iterators in lambdas

Champion issue: https://github.com/dotnet/csharplang/issues/9467
Specification: https://github.com/dotnet/csharplang/blob/ca5b8eb445846c2f5aa394a48cd0992bef76c277/proposals/iterators-in-lambdas.md

We started today with a look at a proposal, allowing lambdas to be iterators. We are overall in support of this proposal, though several open questions will need further looks. The main questions we have are:

• How close should we align with Visual Basic's behavior?
• What should the default return type of an iterator be? IEnumerable, or IEnumerator?
  • We do think that once we decide on that, sync vs async should be easier: lambdas marked async should be IAsyncEnumera(ble|tor), and non-async lambdas would be IEnumera(ble|tor).

We will accept this proposal into the working set for future work.

Conclusion

Proposal accepted, moved to the working set.

Extensions

Champion issue: https://github.com/dotnet/csharplang/issues/8697
Specification: https://github.com/dotnet/csharplang/blob/ca5b8eb445846c2f5aa394a48cd0992bef76c277/proposals/extensions.md
Reviewed Document: https://github.com/dotnet/csharplang/blob/ca5b8eb445846c2f5aa394a48cd0992bef76c277/meetings/working-groups/extensions/content-based-naming.md

We spent most of the meeting reviewing the new proposal for how extension metadata is preserved in naming. One of the key issues we want to address is stability; while these are mostly implementation details to end users, there are various implementation details in the middle that need to care. crefs, for example, or public API tracking across library versions. These intermediates need to understand the metadata layout in order to provide good tracking, and by adjusting our proposed mechanisms, we can better serve these applications while still providing the same end user experience.

One thing we've realized, as we delved into the details here, is that we don't know how to entirely have our cake and eat it too. The runtime does not allow us to overload on constraints, so that means that constraints must be included in the generated names that we end up using. But that also means that removing a constraint becomes a breaking change for these intermediary tools, which is not something that has been true in C# before. We think we're ok with this; for things like the API tracking tools, this is something they can adapt to, and is easier to adapt to than the larger changes that would have happened in the previous versions of the tooling. For crefs, it's unfortunate, but we don't think that crefs are a large enough issue to need further design here. We also considered whether to adopt a version of the encoding that would allow methods to avoid the breaks; properties and events can't avoid it, but methods could. We don't think the tradeoff in complexity is worth it, so we will stick with the initial proposal.

We also considered hashing algorithms for a bit. We're ok with the proposal, particularly the reason for avoiding hashes used in cryptographic scenarios.

Conclusion

New approach is accepted.