an issue with extension methods, where context param(s) preceding receiver break unqualified calls from different methods within the same group/clause.
extension (/* either remove this, or move this to the end, and everything comes back to work! */ using ... ) (x: String)
def m1(): String = ...
def m2(): String = m1().m1()
Compiler version
3.9.0-RC4
3.8.4
3.3.8 and 3.3.2
Minimized code
extension (/* either remove this, or move this to the end, and everything comes back to work! */ using String <:< String ) (x: String)
def dropFirstChar(): String = x.drop(1)
def dropFirstTwoChars(): String = dropFirstChar().dropFirstChar()
val d = "[[Ljava/util/List;"
println(s"mode: ${d}")
println(s"mode: ${d.dropFirstTwoChars()}")
Output
3.9.0-RC4 and 3.8.4 and 3.3.8:
value dropFirstChar is not a member of String <:< String.
Extension methods were tried, but could not be fully constructed:
<:<.refl[String <:< String].apply(x$1)
Playground.dropFirstChar(x$1)(x$1)
failed with:
Found: (x$1 : String <:< String)
Required: String
Expectation
for it to compile and run (behave) equivalently as if the (using String <:< String) were instead at the end or gotten rid of entirely.
specifically, for it to run and print:
mode: [[Ljava/util/List;
mode: Ljava/util/List;
Notes
at some point
I also found a case where a similar pattern (unqualified call to someOtherExtMethod() in-turn defined with inferred type) surprisingly failed with recursive value needs type complaint, where an equivalent qualified call (bar.someOtherExtMethod(), which is, the former plus an extra implicit search!) worked.
an issue with extension methods, where context param(s) preceding receiver break unqualified calls from different methods within the same group/clause.
Compiler version
3.9.0-RC43.8.43.3.8and3.3.2Minimized code
Output
3.9.0-RC4and3.8.4and3.3.8:Expectation
for it to compile and run (behave) equivalently as if the
(using String <:< String)were instead at the end or gotten rid of entirely.specifically, for it to run and print:
Notes
at some point
I also found a case where a similar pattern (unqualified call to
someOtherExtMethod()in-turn defined with inferred type) surprisingly failed withrecursive value needs typecomplaint, where an equivalent qualified call (bar.someOtherExtMethod(), which is, the former plus an extra implicit search!) worked.