Sorry for replying to myself here, but I’ve been reading more of the links provided and re-reading the ones I had found before. I cannot escape the idea that everyone seems to believe that extensions extend a type. For one it is in the documentation:
Extension methods allow one to add methods to a type after the type is defined.
It is mentioned in the proposal from fkowal:
It builds on the knowledge/expectations of how class/trait inheritance works.
…
This trait also extends the type T with additional extension methods
Extension methods are a more straightforward and simpler alternative to implicit classes.
In fact, as som-snytt points out, szeiger raised the exact same issue I raised here, without a resolution that I can see in the thread.
The concept is also raised in PRs:
The aim of this proposal is to
- make typeclasses easy and pleasant to use.
- remove the rift between standard class hierarchies and typeclass hierarchies. Both should be written in the same way and it should be possible to mix both styles and move fluidly between them.
- in conjunction with opaque types, replace the lower-level constructs of value classes and implicit classes.
All type based goals. These same goals are referenced from LukaCJB’s proposal which led to odersky’s PR#5114.
And throughout all of the threads on this topic both in the forums here, in PRs, and everywhere that I can find, there is abundant discussion of the handling of this. Which seems to imply a strong belief that the type definition is the thing being extended. I realize that the final syntax dropped references to this, but what I’m trying to point out is the community understanding of what extension means.
I have seen assertions to this effect elsewhere as well. But based on what seems to me to be abundant evidence that extensions are seen as extending a type, this feels like wishful thinking, not a reflection of the reality “on the ground” so-to-speak. Which is exactly why this topic keeps coming up, multiple bugs are filed, and confusion rules the day with regard to what is meant with this new construct. Everyone thinks it is about types but the implementation thinks it is about method application. And therein lies the bug.
If our goal in language design is to remove friction and enable efficiency among developers using the language, subverting expectations and insisting everyone is wrong is a bug with regard to that goal.
And as we’re discovering, the place where the “bug” is best seen is in the divergent handling of right-associative methods.
Given all this, I think it would very much be a step in the wrong direction to double down on this conflicted definition of extension, remove capabilities from classes, and force the language into a different pattern. That’s a very heavy handed “fix” for the implementation of extension failing to match expectations.