Added in reflect Select.overloaded parameter for expected result type [WIP]

[rssh]

Motivation is described in #10053

[dottybot]

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Commit Messages

We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).

Please stick to these guidelines for commit messages:

1. Separate subject from body with a blank line
2. When fixing an issue, start your commit message with Fix #<ISSUE-NBR>:
3. Limit the subject line to 72 characters
4. Capitalize the subject line
5. Do not end the subject line with a period
6. Use the imperative mood in the subject line ("Add" instead of "Added")
7. Wrap the body at 80 characters
8. Use the body to explain what and why vs. how

adapted from https://chris.beams.io/posts/git-commit

Have an awesome day! ☀️

[bishabosha]

would it make more sense to add a method that can call with all curried parameter lists?

[rssh]

From the point of usability, this can be better, but overloading is defined in language specs only for one parameter list. (https://scala-lang.org/files/archive/spec/2.13/06-expressions.html#overloading-resolution ), I guess because it's a beast from the java world.

(after reading specs: looks like things like:

def f(x:A)(y:B)
def f(x:A)(y:C) 

should not compile at all. But they compiled.

The compiler now counts the weight of the transformations for choosing the best alternative only for the arguments in the first list and uses the second argument list only for return type constraint.

If we extending the notion of overloading to multiple argument lists, then we probably should change the logic of the compiler, to use other lists during the generation of alternatives.

So, the question is in specs: I see 3 variants of resolution

• extend overloading to the list of arguments, change specs, and semantics of resolving overloads. In this case List of list of arguments in API is logical.
• assume that overloading is defined only for the first argument list and other uses as constraints for the return type, add a description of participating return type in alternatives to specs and return API as in this request.
• if we have the next major version, maybe just disallow using return type [write this in specs] and API should not contain anything behind the first argument list (i.e. as now, without this pull request).

Interesting question, I don't know the answer.

[bishabosha]

My suggestion was to keep calling the tpd.applyOverloaded method in its implementation but for the resultType use a MethodType recursively built from the following parameter lists, or wildcard type if there are no more lists. Its just a guess however, I'm not sure what it expects to receive.

[rssh]

yes, .. I thinking this can be viewed as priorities. [i.e. choose the first list of arguments by weight, than second ]. ... but not sure exactly,

I will prepare a variant with the list.

[rssh]

Problem with list of list approach: if we assume that the last type should always be a wildcard, then we can't be able to compile our example: compiler assumes that [PartialFunction[A,B]=>_] and [A=>B]=>_ both satisfy the same constraint. Therefore next code will fail:

package x

object X:

  def andThen[A,B](a:A)(f: A => B): B =
     println("totalFunction")
     f(a)

  def andThen[A,B](a:A)(f: PartialFunction[A,B]): Option[B] =
     println("partialFunction")
     f.lift.apply(a)

object Main:

 def main(args:Array[String]):Unit =
    // compiled
    val x1 = X.andThen(1){case x if (x%2 == 0) => x}
    val x2 = Macro.mThen{case x:Int if (x%2 == 0) => x}

package x

import scala.quoted._

object Macro:

    inline def mThen[A,B](inline x:A=>B):B = ${
       mThenImpl[A,B,A=>B,B]('x)
    }

    inline def mThen[A,B](inline x:PartialFunction[A,B]): Option[B] = ${
       mThenImpl[A,B,PartialFunction[A,B],Option[B]]('x)
    }

    def mThenImpl[A:Type, B:Type, S<:(A=>B) :Type, R:Type](x:Expr[S])(using qctx: QuoteContext):Expr[R]=
       import qctx.reflect._
       val fun = '{X}.unseal
       //val wildcard = TypeBounds(quoted.Type[Nothing].unseal.tpe, quoted.Type[Any].unseal.tpe)
       val wildcard = TypeBounds(TypeIdent(defn.NothingClass).tpe, TypeIdent(defn.AnyClass).tpe)
       val firstPart = Select.overloaded(fun,"andThen",
                                 List(TypeIdent(defn.IntClass).tpe, TypeIdent(defn.IntClass).tpe),
                                 List(Literal(Constant.Int(1))),
                                 quoted.Type[(S) => _].unseal.tpe
                       )
       Apply(firstPart,List(x.unseal)).seal.cast[R]

~   

[nicolasstucki]

The fix seems good. Just needs some changes in the implementation within QuoteContextImpl. I also suggest to add the high and lower bound methods.

[nicolasstucki]

Thank you @rssh