SIP: Auto-tupling of n-ary functions.

Add the following automatic conversion:

Let

F = (p1, ..., pn) => E

for n != 1, parameters p1, ..., pn, and an expression E. If the expected type of F is a fully defined function type or SAM-type that has a single parameter of a subtype of ProductN[T1, ..., Tn], where each type Ti fits the corresponding parameter pi, then F is rewritten to

x => {
   def p1 = x._1
   ...
   def pn = x._n
   E
}

A type T fits a parameter p if one of the following two cases is true:

1. p comes without a type, i.e. it is a simple identifier or _.
2. p is of the form x: U or _: U and T conforms to U.

Auto-tupling composes with eta-expansion. That is an n-ary function generated by eta-expansion can in turn be adapted to the expected type with auto-tupling.

Examples:

val pairs = List(1, 2, 3).zipWithIndex
pairs.map(_ + _)

def plus(x: Int, y: Int) = x + y
pairs.map(plus) 

[som-snytt]

@julienrf https://docs.scala-lang.org/scala3/reference/other-new-features/parameter-untupling-spec.html

[som-snytt]

One fix is to change the migration doc from

Though it is possible that someone has written an implicit conversion form (T1, …, Tn) => R to TupleN[T1, …, Tn] => R for some n.

to

Users may wish to upgrade their implicit conversion from (T1, …, Tn) => R to TupleN[T1, …, Tn] => R to a given Conversion[(T1, ..., Tn) => R, TupleN[T1, ..., Tn] => R.

Actually, the naive implicit transparent inline def conversion does the obvious, efficient thing.

It’s OK to transparent inline given Conversion but you can’t “nest” a transparent inline def apply, so there is an extra apply.

TIL TIL stands for transparent inline love.

Update: I did PR the explanation on the doc page. Unfortunately, it is not as droll as my comment here. Thanks @julienrf for raising awareness.

This issue or edge case is similar to the issue about rewrapping context functions: the adaptation is syntax-driven, or is a function of syntax, so it’s a surprise that it is not type-driven.