FunctionN tupled should return (ProductN) => T not (TupleN) =>T

[scabug]

scala> import scala.language.postfixOps
import scala.language.postfixOps

scala> case class Foo (i:Int, j:Int)
defined class Foo

scala> Foo.apply _ tupled
res2: ((Int, Int)) => Foo = <function1>

I would expect that res2's type is (Product2) => Foo

I'm happy to produce a patch assuming it's agreed that this behaviour is incorrect.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-8986?orig=1
Reporter: Mark Lister (marklister)
Affected Versions: 2.11.4

[scabug]

@retronym said:
If we make this change, we would also need to touch the corresponding Function.tupled methods.

Changes of this nature, however, usually have subtle source incompatibilities.

This is contrived, but shows how in the presence of type inference, this seemingly compatible change could break someones code:

scala> def tupled[A, B, C](f: (A, B) => C): (Product2[A, B] => C) = ???
tupled: [A, B, C](f: (A, B) => C)Product2[A,B] => C

scala> def client(f: (Int, Int) => Int) = Set[((Int, Int)) => Int](tupled(f))
client: (f: (Int, Int) => Int)scala.collection.immutable.Set[((Int, Int)) => Int]

scala> def client(f: (Int, Int) => Int): Set[((Int, Int)) => Int] = {val result = Set(f.tupled); result}
client: (f: (Int, Int) => Int)Set[((Int, Int)) => Int]

scala> def client(f: (Int, Int) => Int): Set[((Int, Int)) => Int] = {val result = Set(tupled(f)); result}
<console>:34: error: type mismatch;
 found   : scala.collection.immutable.Set[Product2[Int,Int] => Int]
 required: Set[((Int, Int)) => Int]
Note: Product2[Int,Int] => Int <: ((Int, Int)) => Int, but trait Set is invariant in type A.
You may wish to investigate a wildcard type such as `_ <: ((Int, Int)) => Int`. (SLS 3.2.10)
       def client(f: (Int, Int) => Int): Set[((Int, Int)) => Int] = {val result = Set(tupled(f)); result}
                                                                                                  ^

I'll assign this Rex for his opinion.

[scabug]

Mark Lister (marklister) said:
#1799 (Case classes should inherit from ProductN) might be relevant.

[scabug]

@Ichoran said:
I do not think that returning a more specific type is a bug. Yes, it's in contravariant position, so it means you can stuff your arbitrary Product2 into that function, but this also means that the code can (in principle, anyway) be more aggressively optimized, which is especially important for functions.

So, [~marklister], I would want to see a more compelling argument for why Product2 is what we normally want. And, also, why this should be what tupled always does instead of also having a fromProduct method.

[scabug]

Mark Lister (marklister) said:
Rex Kerr, I must admit I approached this quite naïvely:

• Once SI-1799 is complete (if ever) tuples and case classes will become entirely interchangeable. I expected case classes to implement ProductN and therefore the common type is ProductN. I may have misread SI-1799 and how it should work.

you can stuff your arbitrary Product2 into that function

I'm not sure how to do that. Here's what happens when I try:

Type in expressions to have them evaluated.
Type :help for more information.

scala> import scala.language.postfixOps
import scala.language.postfixOps
scala> case class Foo (i:Int, j:Int)
defined class Foo

scala> Foo.apply _ tupled
res3: ((Int, Int)) => Foo = <function1>

scala> val prod:Product2[Int,Int]= (2,3)
prod: Product2[Int,Int] = (2,3)

scala> res3 (prod)
<console>:20: error: type mismatch;
 found   : Product2[Int,Int]
 required: (Int, Int)
              res3 (prod)
                    ^

That said I must just point out I'm not really intellectually equipped to argue this robustly. If you're sure that tuple is correct that's good enough for me.