You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This patch removes the special treatment of extension methods while
desugaring. Instead of swapping the arguments of the extension method
at definition site, we let the usual desugaring take care of it.
```scala
extension (xs: List[Int]) def -:(x: Int) = xs.remove(x)
1 -: List(2, 3) // desugars into List(2, 3).-:(1)
1 :: List(2, 3) // desugars into List(2, 3).::(1)
```
This implies that the following makes sense now:
```scala
List(2, 3).-:(1) // equivalent to the one bellow
-:(List(2, 3))(1)
```
Note that the parameters are passed in order as in the signature,
as they should. This used to break intuition in the previous implementation.
Futhermore, this fixes parameter scoping and dependencies, as it trivially
respects the original signature. An example of this is in the following
code example, where `T` is bounded by `tuple.type`, which would have been
out of scope in the previous implementation due to the swapping of parameters.
```scala
extension (tuple: Tuple)
def *:[T >: tuple.type <: Tuple, H](x: H): H *: T = ...
```
The downside is that this is a breaking change as we change the semantics
of the extension method definitions. We need to find a way to migrate from
one to the other without breaking code. One option might be to have a
different syntax for the new semantics, and deprecate the old one. One
possibility would be to use `infix def` extensions to mark to mark these
methods.
One issue encountered in the library is with the `IArray.{++:, +:}`
operations. Luckily, it seems that by rewriting them into the new
semantics we get a binary and TASTy compatible signature.
Fixes#19197
0 commit comments