Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
scabug opened this issue Jun 18, 2010 · 11 comments
Open

Comments

@scabug
Copy link

scabug commented Jun 18, 2010

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
Copy link
Author

scabug commented Jun 18, 2010

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

@scabug
Copy link
Author

scabug commented Jul 11, 2010

@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
Copy link
Author

scabug commented Jul 11, 2010

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

@scabug
Copy link
Author

scabug commented Jul 11, 2010

@scabug
Copy link
Author

scabug commented Oct 10, 2012

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

@scabug
Copy link
Author

scabug commented Mar 11, 2014

@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

@adriaanm adriaanm modified the milestones: 2.13.0-RC1, Backlog Jan 8, 2019
@scala scala deleted a comment from scabug Mar 27, 2023
@SethTisue
Copy link
Member

SethTisue commented Mar 27, 2023

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
Copy link
Member

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
Copy link
Member

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?

@SethTisue SethTisue changed the title Spec doesn't mention automatic tupling Automatic tupling isn't spec'ed and should perhaps be not deprecated (not just linted) Mar 27, 2023
@SethTisue SethTisue changed the title Automatic tupling isn't spec'ed and should perhaps be not deprecated (not just linted) Auto-tupling of values isn't spec'ed and should perhaps be not deprecated (not just linted) Mar 27, 2023
@SethTisue SethTisue changed the title Auto-tupling of values isn't spec'ed and should perhaps be not deprecated (not just linted) Auto-tupling isn't spec'ed and should perhaps be not deprecated (not just linted) Mar 27, 2023
@SethTisue SethTisue changed the title Auto-tupling isn't spec'ed and should perhaps be not deprecated (not just linted) Auto-tupling isn't spec'ed and should perhaps be deprecated (not just linted) Mar 27, 2023
@eed3si9n
Copy link
Member

eed3si9n commented Mar 27, 2023

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
Copy link
Member

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants