- "Part of me wants to trust you , but part of me does not" "I would recommend not"
Champion issue: #5497
Documents:
- https://github.com/dotnet/csharplang/blob/e84c2c9711c269243bb2084700512e3f002fec8b/meetings/working-groups/extensions/extensions-an-evolution-of-extension-methods.md
- https://github.com/dotnet/csharplang/blob/e84c2c9711c269243bb2084700512e3f002fec8b/meetings/working-groups/extensions/compromise-design-for-extensions.md
Today, we took a look at another set of proposals around moving forward on extension types; one taking a more member-centric approach, and the other taking a more type-centric
approach. These proposals also tried to lay out visions for how we might balance tradeoffs. Most the meeting was simply spent reading over and clarifying these proposals. We
also went and collected some statistics around extensions from a few popular libraries, using https://github.com/DustinCampbell/ExtensionMethodDumper. This data covers how many
types are used as a this parameter in a given extension type. If we then assume that each of those static classes would need to be split up into extension types for each receiver,
we get:
- .NET libraries: 496 types goes to 1165 types. Ratio: 2.35
- ASP.NET: 536 types goes to 640: Ratio 1.19
- Roslyn: 782 types goes to 1753 types: Ratio 2.24
- FluentAssertions: 43 types goes to 170 types: Ratio 3.95
FluentAssertions is a particular outlier in our data here. More than half of that increase comes from a single type, FluentAssertions.AssertionExtensions, which has 85 receiver
types on 97 methods.
Another point that was brought up during the meeting is that we're trying to weigh several different types of "complexity", given our existing language. A type-based extension world would very likely require fewer overall concepts in the language, if we were starting from scratch. However, we're not starting from scratch; we're starting from C# as it exists. We already have member-based approaches in the language, and repurposing them may give us a future with a lower concept count given where we're starting.
This gives us a lot more to think about, so we'll come back in a couple of weeks to discuss yet again.