SI-7296 Lifting the limit on case class arity #2305
Conversation
The implementation restriction doesn't stop subsequent typechecking in the same compilation unit from triggering type completion which tries to synthesize the unapply method. This commit predicates generation of the unapply method on having 22 or fewer parameters.
When venturing above the pre-ordained limit of twenty two, `Companion extends FunctionN` and `Companion.unapply` are sacrificed. But oh-so-many other case class features work perfectly: equality/hashing/stringification, the apply method, and even pattern matching (which already bypasses unapply.) There was some understandable fear of the piecemeal when I tabled this idea on scala-internals [1]. But I'd like to persist as this limit is a needless source of pain for anyone using case classes to bind to database, XML or JSON schemata. [1] https://groups.google.com/forum/#!topic/scala-internals/RRu5bppi16Y
|
LGTM. This should have no impact on Slick at the moment but could be used to map case classes with higher arities once we can generate unboxed access paths that avoid the intermediate tuples. Attempts to use large case classes when going through tupled APIs may lead to surprising error messages. I have opened SI-7299 for that. |
|
Good catch, I've sharpened up the error message in #2306. |
ghost
assigned 
|
Is there any opportunity to warn about the differences from 22-and-under case classes without being annoyingly noisy? The enumerated distinctions seem like things which would turn up as "it doesn't compile anymore", not as hidden traps, so I'm not too fretty about it; but when there is a switch flipped at an utterly arbitrary number it feels like something somewhere ought to openly recognize the event, at the least if the user gives any sign of being interested in hearing about more things (e.g. -Xlint.) |
|
We could mandate the import of |
|
LGTM |
SI-7296 Lifting the limit on case class arity
The first commit fixes a crasher with the limit still imposed, that shows up with nested fat case classes.
The second lifts the limit. For case classes with > 22 params:
unapplyFunctionN.There was some understandable fear of the piecemeal when
I tabled this idea on scala-internals [1]. But I'd like
to persist as this limit is a needless source of pain for
anyone using case classes to bind to database, XML or JSON
schemata.
Review by @paulp @szeiger (for a Slick perspective), and by the Scala Meeting tomorrow.
[1] https://groups.google.com/forum/#!topic/scala-internals/RRu5bppi16Y