Extension methods ambiguity when type argument is added

[soronpo]

Just adding a type argument causes the compiler to report ambiguity where there is none.

Compiler version

v3.1.2-RC1

Minimized code

https://scastie.scala-lang.org/cI1XmUISRwmnIqc8rOThSw

class Foo

extension (dfVal: Foo)
  def prevOK(step: Int): Foo = ???
  def prevOK: Foo = ???
val ok = (new Foo).prevOK

extension (dfVal: Foo)
  def prevErr[S <: Int](step: S): Foo = ???
  def prevErr: Foo = ???
val err = (new Foo).prevErr

Output

value prevErr is not a member of Playground.Foo.
Extension methods were tried, but could not be fully constructed:

    Playground.prevErr(new Playground.Foo())

    prevErr(new Playground.Foo())    failed with

        Ambiguous overload. The overloaded alternatives of method prevErr in object Playground with types
         (dfVal: Playground.Foo): Playground.Foo
         (dfVal: Playground.Foo): [S <: Int](step: S): Playground.Foo
        both match arguments (Playground.Foo)

Expectation

No error.

[soronpo]

May be related to #14450

[prolativ]

If you paste your examples you should see the reason why this doesn't work.
First one has keep in mind that extension methods eventually get desugared to normal methods.
So for

extension (dfVal: Foo)
  def prevOK(step: Int): Foo = ???
  def prevOK: Foo = ???

you get

def prevOK(dfVal: Foo)(step: Int): Foo
def prevOK(dfVal: Foo): Foo

This is an overloaded method with a different number of parameter lists but the compiler is smart enough to distinguish between them at compile time in most cases.

But in case of

extension (dfVal: Foo)
  def prevErr[S <: Int](step: S): Foo = ???
  def prevErr: Foo = ???

you get

def prevErr(dfVal: Foo): [S <: Int](step: S): Foo
def prevErr(dfVal: Foo): Foo

Now both of the overloaded variants take just a single parameter but they have different return types and it's not clear for the compiler which one you would like when writing

val err = (new Foo).prevErr

The reason for a different desugaring is that currently you cannot have a method like def prevErr(dfVal: Foo)[S <: Int](step: S): Foo with interweaved value and type parameters. I hope this restriction will get releaxed soon but I'm not sure of its status #14019

You can make your example compile by specifying the result type explicitly, e.g.

val err: Foo = (new Foo).prevErr

[soronpo]

Ok. Thanks. I guess that in the meanwhile it's another one for my growing list of examples where extension methods cannot replace implicit classes.

[Sporarum]

But in case of

extension (dfVal: Foo)
  def prevErr[S <: Int](step: S): Foo = ???
  def prevErr: Foo = ???

you get

def prevErr(dfVal: Foo): [S <: Int](step: S): Foo
def prevErr(dfVal: Foo): Foo

This is somewhat misleading, the actual translation would be pretty printed as:

def prevErr(dfVal: Foo)[S <: Int](step: S): Foo
def prevErr(dfVal: Foo): Foo

The actual representation is a MethodType returning a PolyType returning a MethodType returning a Foo
This is similar to the actual representation for prevOk: a MethodType returning a MethodType returning a Foo
This is because MethodType contains only one (term) clause

Clause Interweaving doesn't change the representation inside the compiler, it uses the one introduced by #10950
(which I described above)

I believe the check that allows ok assumes there can only be MethodType as return, and doesn't handle PolyType.
(Thus the fix should be fairly easy)

Even if that is not the case, merging Clause Interweaving would not solve the problem, as it doesn't change the representation used
(but solving the problem is important for Clause Interweaving)

[Sporarum]

The reason for a different desugaring is that currently you cannot have a method like def prevErr(dfVal: Foo)[S <: Int](step: S): Foo with interweaved value and type parameters.

My previous message could be simplified to:

This method is completely allowed inside the compiler
But users can only create it through extension methods
Clause Interweaving only adds the ability for users to create those methods directly

[soronpo]

It's good to document the workaround. We can move the type argument to the extension in many cases:

extension [S <: Int](dfVal: Foo)
  def prevErr(step: S): Foo = ???
  def prevErr: Foo = ???
val err = (new Foo).prevErr

[Sporarum]

It turns out this is relatively easy to fix:
#14451

It does not require clause interleaving, but it would have made overloading with it very limited