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

Deprecation story for auto-tupling #496

Open
adriaanm opened this issue May 4, 2018 · 5 comments
Open

Deprecation story for auto-tupling #496

adriaanm opened this issue May 4, 2018 · 5 comments
Assignees
Milestone

Comments

@adriaanm
Copy link
Contributor

@adriaanm adriaanm commented May 4, 2018

(to flesh out)

@eed3si9n
Copy link
Member

@eed3si9n eed3si9n commented May 4, 2018

Ref:

@SethTisue
Copy link
Member

@SethTisue SethTisue commented Aug 7, 2018

@adriaanm is this something we need to make sure happens for RC1?

@SethTisue SethTisue removed this from the 2.13.0-M5 milestone Aug 7, 2018
@SethTisue SethTisue added this to the 2.13.0-RC1 milestone Aug 7, 2018
@adriaanm
Copy link
Contributor Author

@adriaanm adriaanm commented Aug 7, 2018

I think we can figure this (and any other deprecation strategy) out early in the 2.13.x cycle.

@adriaanm adriaanm removed this from the 2.13.0-RC1 milestone Aug 7, 2018
@adriaanm adriaanm added this to the 2.13 milestone Aug 7, 2018
@Jasper-M
Copy link
Member

@Jasper-M Jasper-M commented Aug 27, 2018

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

@SethTisue SethTisue commented Nov 3, 2018

eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2019
Ref scala/scala-dev#496
Ref lampepfl/dotty#4311 (comment)

Using the `compileTimeError` annotation, this removes the multi-parameter, vararg variants of `+` and `-` operators from the collections, and instructs the users to migrate to `++` and `--` instead.

This is part of an effort to remove the ambiguity between tuple literal and parameter list when in an infixed operator notation.
eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2019
Ref scala/scala-dev#496
Ref lampepfl/dotty#4311 (comment)

Using the `compileTimeError` annotation, this removes the multi-parameter, vararg variants of `+` and `-` operators from the collections, and instructs the users to migrate to `++` and `--` instead.

This is part of an effort to remove the ambiguity between tuple literal and parameter list when in an infixed operator notation.
eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2019
Ref scala/scala-dev#496
Ref lampepfl/dotty#4311 (comment)

Using the `compileTimeError` annotation, this removes the multi-parameter, vararg variants of `+` and `-` operators from the collections, and instructs the users to migrate to `++` and `--` instead.

This is part of an effort to remove the ambiguity between tuple literal and parameter list when in an infixed operator notation.
@szeiger szeiger removed this from the 2.13.1 milestone Sep 9, 2019
@szeiger szeiger added this to the 2.13.2 milestone Sep 9, 2019
@SethTisue SethTisue removed this from the 2.13.2 milestone Feb 6, 2020
@SethTisue SethTisue added this to the 2.13.3 milestone Feb 6, 2020
@SethTisue SethTisue removed this from the 2.13.3 milestone May 15, 2020
@SethTisue SethTisue added this to the 2.13.4 milestone May 15, 2020
@dwijnand dwijnand removed this from the 2.13.4 milestone Oct 16, 2020
@dwijnand dwijnand added this to the Backlog milestone Oct 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants