Scala-dev: Deprecation story for auto-tupling

Created on 4 May 2018  路  5Comments  路  Source: scala/scala-dev

(to flesh out)

picture adriaanm
👍2

Most helpful comment

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).

picture Jasper-M on 27 Aug 2018
👍3

All 5 comments

Ref:

eed3si9n picture eed3si9n on 4 May 2018

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

SethTisue picture SethTisue on 7 Aug 2018

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

adriaanm picture adriaanm on 7 Aug 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).

Jasper-M picture Jasper-M on 27 Aug 2018
👍3

new plan at https://github.com/lampepfl/dotty/pull/4311#issuecomment-435593905

SethTisue picture SethTisue on 3 Nov 2018
Was this page helpful?
0 / 5 - 0 ratings

Related issues

lrytz picture lrytz  路  4Comments
KieranPringle picture KieranPringle  路  7Comments
adriaanm picture adriaanm  路  8Comments
adriaanm picture adriaanm  路  7Comments
adriaanm picture adriaanm  路  4Comments