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

Closed
adriaanm opened this issue May 4, 2018 · 7 comments
Closed

Deprecation story for auto-tupling #496

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

Comments

@adriaanm
Copy link
Contributor

adriaanm commented May 4, 2018

(to flesh out)

@eed3si9n
Copy link
Member

eed3si9n commented May 4, 2018

Ref:

@SethTisue
Copy link
Member

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

@SethTisue SethTisue modified the milestones: 2.13.0-M5, 2.13.0-RC1 Aug 7, 2018
@adriaanm
Copy link
Contributor Author

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 modified the milestones: 2.13.0-RC1, 2.13 Aug 7, 2018
@Jasper-M
Copy link

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 commented Nov 3, 2018

new plan at scala/scala3#4311 (comment)

eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2019
Ref scala/scala-dev#496
Ref scala/scala3#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 scala/scala3#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 scala/scala3#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 modified the milestones: 2.13.1, 2.13.2 Sep 9, 2019
@SethTisue SethTisue modified the milestones: 2.13.2, 2.13.3 Feb 6, 2020
@SethTisue SethTisue modified the milestones: 2.13.3, 2.13.4 May 15, 2020
@dwijnand dwijnand modified the milestones: 2.13.4, Backlog Oct 16, 2020
@SethTisue
Copy link
Member

Out of scope for Scala 2

@SethTisue
Copy link
Member

Well, perhaps not out of scope. I just added some remarks at scala/bug#3583 (comment) . Let's leave this one closed and let discussion continue there.

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

No branches or pull requests

6 participants