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

Comments

@adriaanm
Copy link
Member

commented May 4, 2018

(to flesh out)

@adriaanm adriaanm added this to the 2.13.0-M5 milestone May 4, 2018

@adriaanm adriaanm self-assigned this May 4, 2018

@eed3si9n

This comment has been minimized.

Copy link
Member

commented May 4, 2018

Ref:

@SethTisue

This comment has been minimized.

Copy link
Member

commented Aug 7, 2018

@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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Nov 3, 2018

eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2019

Remove multi-parameter, vararg variant of + and -
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

Remove multi-parameter, vararg variant of + and -
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

Remove multi-parameter, vararg variant of + and -
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.