Add experimental TupledFunction

[nicolasstucki]

This reverts commit f4e1ca4.

Originally added in #6568.

[nicolasstucki]

We should also revisit #14138 once this is merged.

[milessabin]

Does this generalize to polymorphic functions?

Ie. given [a, b] => (a, b) => C we should be able to get to [a, b] => ((a, b)) => C.

[nicolasstucki]

Does this generalize to polymorphic functions?
Ie. given [a, b] => (a, b) => C we should be able to get to [a, b] => ((a, b)) => C.

My intuition tells me it is possible. The interface has nothing that depends on normal lambdas. The compiler should be able to synthesize TupledFunction[[a, b] => (a, b) => C, [a, b] => ((a, b)) => C] as it does for any supported function type. Then we would need to add the erased implementation for those instances or use the ones that are already defined.

@milessabin do you have a concrete where this would be useful?

[milessabin]

@nicolasstucki yes, I do ... various higher-kinded transformations.

But also, more generally, it'd be good to keep parity between monomorphic and polymorphic functions wherever possible.

[nicolasstucki]

@nicolasstucki yes, I do ... various higher-kinded transformations.

@milessabin could you share a couple of representative examples to include in tests?

[nicolasstucki]

We should probably start with the non-polymorphic version and extend it later. I do not have time right now to implement the extension. If we have the current version as experimental library authors could start experimenting with it and provide feedback.

[smarter]

Are dependent functions supported? e.g. (x: Int, y: Int) => List[x.type]

[nicolasstucki]

Are dependent functions supported? e.g. (x: Int, y: Int) => List[x.type]

Not sure. I would have to double-check and possibly improve later.

That would mean the tupled version of the function is (args: (Int, Int)) => List[args._1.type]. This might not scale to functions larger than 22 as we do not have the _N stable paths.