EtaExpansion

The type of the method reference

The tree to expand

The arity of the expected function type and assume the lifted application of tree (@see liftApp) is { val xs = es; expr } The result of the eta-expansion is either (1) { val xs = es; (x1, ..., xn) => expr(x1, ..., xn) } or (2) { val xs = es; (x1: T1, ..., xn: Tn) => expr(x1, ..., xn) } or (3) { val xs = es; (x1: T1, ..., xn: Tn) => expr(x1, ..., xn) _ } where T1, ..., Tn are the paremeter types of the expanded method. If expr has implicit function type, the arguments are passed with given. E.g. for (1): { val xs = es; (x1, ..., xn) => expr(using x1, ..., xn) } Case (3) applies if the method is curried, i.e. its result type is again a method type. Case (2) applies if the expected arity of the function type xarity differs from the number of parameters in mt. Case (1) applies if mt is uncurried and its number of parameters equals xarity. In this case we can always infer the parameter types later from the callee even if parameter types could not be inferred from the expected type. Hence, we lose nothing by omitting parameter types in the eta expansion. On the other hand omitting these parameters keeps the possibility open that different parameters are inferred from the expected type, so we keep more options open. In each case, the result is an untyped tree, with es and expr as typed splices. FV ==> (x => F[X]) Note: We allow eta expanding a method with a call by name parameter like def m(x: => T): T to a value of type (=> T) => T. This type cannot be written in source, since by-name types => T are not legal argument types. It would be simpler to not allow to eta expand by-name methods. That was the rule initially, but at some point, the rule was dropped. Enforcing the restriction again now would break existing code. Allowing by-name parameters in function types seems to be OK. After elimByName they are all converted to regular function types anyway. But see comment on the ExprType case in function prune in class ConstraintHandling.