Auto-tupling isn't spec'ed and should perhaps be deprecated (not just linted)

[scabug]

From Typers:

/** Try packing all arguments into a Tuple and apply `fun'
           *  to that. This is the last thing which is tried (after
           *  default arguments)
           */

I couldn't find this in the spec.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-3583?orig=1
Reporter: @retronym

[scabug]

@retronym said:
While we're at it, we could make this safer by:

• warning if auto tupling chooses one of overloaded alternatives
• warning if any auto-tupling occurs if -Xwarn-auto-tupling is specified.

[11:13pm] paulp: So I change from one joda time class with a 7-arg constructor to a similar one with fewer.
[11:13pm] paulp: but in addition to not having a 7-arg constructor, it has one which takes Object.
[11:14pm] paulp: so no warning until runtime failure "what the <expletive deleted> is a 7-tuple?" says joda time.
[11:14pm] paulp: that is an absolute debacle. 
[11:14pm] paulp: I knew about this issue but it never bit me this ugly before.
[11:16pm] retronym: -Xwarn-auto-tupling would be popular, from my straw polls
[11:19pm] retronym: paulp: or just outright disable it if there are overloaded alternatives

[scabug]

@retronym said:
A warning could also be emitted if the target method is defined in Java.

[scabug]

@retronym said:
See: http://thread.gmane.org/gmane.comp.lang.scala.debate/4954

[scabug]

@paulp said:
There has been a warning available since scala/scala@4e488a60594 and the warning is included in -Xlint.

[scabug]

@adriaanm said:
Not classifying as a spec bug, because I believe we should instead deprecate this. See also the discussion over at Dotty, where I hope this won't be implemented at all: scala/scala3#51

[SethTisue]

It's been a while since we looked at the linting/deprecation story here.

As of 2.13.10, it still is only a lint (no warning without -Xlint).

Scala 3, to my dismay, doesn't even warn, not even under -source:future.

I found scala/scala3#85, which does add the following:

scala> import language.noAutoTupling                                                                                             
scala> def foo(x: Any) = (); foo(1, 2)
Error:  too many arguments for method foo: (x: Any): Unit

Not sure where subsequent chapters in the Scala 3 story, if any exist, might be found in GitHub and/or forums. The searching becomes difficult because Scala 3 added a different kind of "auto-tupling", the kind that is specific to function literals and permits one to write e.g. xs.collect((x, y) => ...) instead of xs.collect{case (x, y) => ...}.

I'm still eager to hasten the old kind of auto-tupling's exit from the language, but if Scala 3 hasn't sped that up yet, then it would arguably be odd for us to be more aggressive (for example, by deprecating under -Xsource:3).

[SethTisue]

On scala/scala-dev#496 (which is now closed in favor of this one), @Jasper-M made some useful remarks I'd like to reproduce here:

I would just like to point out that once you have HList-like tuples in Scala 3, having auto-tupling only for arguments which have a Tuple upper bound is a pretty great way to have syntax-free arity abstraction. It seems a bit strange to on the one hand build arity abstraction into the language and std library, and on the other remove a feature that could make arity abstraction great, which was available when arity abstraction was hard to do anyway.

I don't think it could still cause confusion or weird runtime errors either, since auto-tupling will only happen when a tuple is already expected.

The reason that right now not much breaks between removing auto-tupling for Any or Unit bounded arguments, and removing it for everything, is probably that

• currently you have to use a bunch of Shapeless macros to convert between tuples and hlists,
• currently tuples don't even share a common type, other than Product which all case classes have, and
• no one in their right mind would write def foo(a: (Int, Int)) or def foo[A <: (Int, Int)](a: A), cause right now it's used exactly the same as def foo(a: Int, b: Int) except it has a bunch of extra overhead.

Without auto-tupling I think I would actually prefer (syntax-wise) shapeless hlists over built-in tuples-as-hlists. To me foo((1, 2, 3)) looks worse/weirder/uglier than foo(1 :: 2 :: 3 :: HNil).

[SethTisue]

There is a bunch of Scala 3 discussion at scala/scala3#4311 . At one point Martin expresss an intent to deprecate in 3.0, and it's unclear to me why it didn't happen — oversight, or change of heart?

[eed3si9n]

In Let’s drop auto-tupling thread, I proposed creating a marker trait:

scala> trait ParamList[A]
defined trait ParamList

scala> def foo[A: ParamList](params: A): Unit = ???
foo: [A](params: A)(implicit evidence$1: ParamList[A])Unit

This can inform the compiler that you're using Shapeless and you do want to pass in a tuple to foo.

Edit: Maybe an annotation like @autoTupling on the method or @paramList on the parameter would be better for binary compatibility.

[SethTisue]

New Scala 3 ticket/discussion: scala/scala3#19255

If Scala 3 decides to deprecate, we could deprecate as well under -Xsource:3.