Should we continue to generate function parents for case companions?

[odersky]

We currently generate a function type parent type for case class companions like this. Given:

case class C(a: A)

the companion is

object C extends (A => C) { ... }

However, there are many restrictions. We do not generate a function type for the companion, if

• the companion is already written
• the case class is polymorphic
• the case class has more than one parameter list
• the constructor of the class is private or qualified private
• the class is an enum case, see: 7ccc244 of Change enum Desugarings #6154.

The question is, given all these restrictions, should we stop generating function parents altogether? It would mean one has to write C(_) instead of C to convert C to a function, but that's probably not such a big deal.

[nafg]

It's useful for Slick: You do (colA, colB) <> (C.tupled, C.unapply), or (colA, colB).mapT[C] (a macro that generates the former). Once you add a companion you have to write (C.apply _).tupled (and if you overload apply it's much worse). Of course, Slick could be changed to not need a unary tupled function...

…

On Thu, Mar 28, 2019 at 4:08 PM odersky ***@***.***> wrote: We currently generate a function type parent type for case class companions like this. Given: case class C(a: A) the companion is object C extends A => C However, there are many restrictions. We do not generate a function type for the companion, if - the companion is already written - the case class is polymorphic - the case class has more than one parameter list - the constructor of the class is private or private protected - the class is an enum case with an undetermined (at the time) parent type see: 7ccc244 <7ccc244> of #6154 <#6154>. The question is, given all these restrictions, should we stop generating function parents altogether? It would mean one has to write C(_) instead of C to convert C to a function, but that's probably not such a big deal. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6190>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGAUIs5AaUadTnif_9cV3GtZcONh0rhks5vbSFUgaJpZM4cRCfX> .

[ritschwumm]

i'd remove it:

it's frustrating when you try to use C as a function and the compiler tells you "no, that works elsewhere but not in this case, please try again differently". it's frustrating when you add a type parameter to your case class and suddenly you have to change every place that was relying on the companion being a function.

personally, i made it a habit to always write C.apply to avoid these (small) frustrations so i won't miss it at all.

[nafg]

How about we remove it in Scala 3.2

…

On Thu, Mar 28, 2019 at 4:19 PM ritschwumm ***@***.***> wrote: i'd remove it: it's frustrating when you try to use C as a function and the compiler tells you "no, that works elsewhere but not in *this* case, please try again differently". it's frustrating when you add a type parameter to your case class and suddenly you have to change every place that was relying on the companion being a function. personally, i made it a habit to *always* write C.apply to avoid these (small) frustrations so i won't miss it at all. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6190 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGAUMjQCljVegdWjuM6jIQiNzmMJmXzks5vbSPNgaJpZM4cRCfX> .

[odersky]

Maybe one can compensate for the loss by upgrading automatic conversions. Specifically, try to insert apply if an expression is not compatible with its expected function type.

[hrhino]

I've never liked this, so 👍 to its removal.

I don't know how the auto-apply could help slick: in C.tupled the expected type of C (as I understand it) is ? { def tupled: ? } (maybe not in dotty?), so you'd need to be willing to treat that auto-apply similarly to an implicit conversion: there's no function type expected.

That said, Slick is how I first ran into this irregularly way back when. Is there a reason why (C.apply.tupled, C.unapply) isn't any good (other than its relative verbosity)? I don't think it works in Scala 2, but IIRC dotty is a bit more willing to eta-expand... would that work?