- "If I had a penny
foreachcode-based dad joke..." - "If we can have our cake and eat it too, I love it. I like cake, and I like eating."
Champion issue: #5497
Related: https://github.com/dotnet/csharplang/blob/1e8255a438517bc3ad067c726c28cfa20cb60f1e/meetings/working-groups/extensions/extensions-as-static-types.md, #8472
Continuing our discussion from last time, we started to explore the pros and cons of moving to a per-member syntax, instead of per-type.
Per-member would naturally lead to a single-pass generic inference algorithm, since everything is in the same signature, but brings its own complexities. Today, properties
and operators cannot introduce type parameters; in order to extend generic types, a per-member syntax would need to come up with a way to introduce that; it seems unlikely
that we would want to require that any extension properties or operators must be on substituted generic types (to put it mildly). However, we're concerned that per-member
syntax could be worse overall; it doesn't improve on how a series of extension methods today are required to repeat the same type over and over. It also looks closer to
what an actual member of the original type looks like. This, of course, then leads to its own set of problems, such as the inability to specify whether this is ref or
scoped for structs. And the compat story becomes, as previously discussed, more complex.
One thing we clarified during discussion is that, even though we've arrived at the idea that extension types aren't actually types and can't be the type of an instance variable today, we haven't ruled out that extension types could implement interfaces in the future, allowing the user to implicitly treat the underlying type as having implemented that interface without having to do any casts.
To try and help drive conversation, we also went through some discussion on what compat means in the context of extensions, reviewing
this document. Compat can mean "keep your existing methods as they are, unchanged, and put new stuff in a new extension type", or it
could mean "everything can move forward to the new form". Along the latter line, we also started thinking about whether there's a unifying for clause that can applied
to members as well as on types, and then have some sort of grow-up story between them. The story would likely still be complex; the generic inference question is still
gnarly. But we think that this is the next area to explore, and will come back next meeting with proposals on it to consider.