- "And then I had a final point that is evading me right now and I was trying to stretch my words to see if it pops in there, but it hasn't quite yet, so I'm going to give it over to "
Champion issue: #5497
Related: https://github.com/dotnet/csharplang/blob/d5b8e7808998024e4aa6b380acdccac30aa03b60/proposals/extensions_v2.md, #8496
Coming back from last time, we wanted to explore different compatibility stories for extensions, and look at what a member-based syntax would look like.
We spent the first half of the meeting listening to presentations about the 2 different explorations that came from this; the first exploration is maximally binary compatible, using a
member-based for syntax that enables all current extension methods to move to a newer form while still being 100% binary compatible with their existing form. The second proposal we
went over was how interop would work in a world where we don't do this, and instead say that existing extension methods are here to stay, forever; the new way is the new way, and if a
user wants perfect binary compat, the only way they get it is through keeping their existing methods as they are.
We came up with a few concerns for each proposal through discussion in the second half.
- Even if there's a fully compatible new syntax, we can't eliminate old style extension methods from the world. Old codebases will continue to exist, and many users will simply not move forward for a variety of reasons.
- The fully compatible proposal will also leave us in a world with 3 different types of extensions: old style, new member style, and eventually, new type style. We will likely still need to have the discussion on how generic inference will work in the new type style extensions, as all our previous arguments around looking more like types than like members will still apply.
- The least compatible proposal ends up exposing each decision through refactorings. There will undoubtedly be fixers from both the Roslyn team and other environments to help users move forward to the new form wherever possible, and anywhere the fixers can't run because the meaning changes exposes design decisions.
- It's possible that the second proposal is somewhat of a subset of the first; is it possible that we could do the second, get that into preview, then wait for feedback on whether a fully compatible form is necessary?
- On the other hand, it's possible that we may want to avoid a type syntax entirely for extensions if we went with the member approach, as it would muddy understanding of what the feature is: a fancy place to put a parameter, that's it.
- Finally, if we go with the member approach, we need to discuss whether we want to support generic properties and operators in general, since it's an obvious next question if we allow extension operators and properties to be generic.
We didn't come to any conclusions today, so we'll be back again with more extensions in the future.