Not that I've actually come close to that limit, but Ive always wondered: Why do they stop at Function22
/Tuple22
. JVM restriction? Arbitrary choice?

- 3,411
- 2
- 22
- 21
-
1http://scala-programming-language.1934581.n4.nabble.com/Scala-API-why-like-this-td1952388.html – rwong Nov 11 '10 at 07:38
-
http://jnordenberg.blogspot.com/2008/09/hlist-in-scala-revisited-or-scala.html – rwong Nov 11 '10 at 07:39
-
Those limits are still there 6 years later: http://stackoverflow.com/a/39981285/6309 – VonC Oct 11 '16 at 15:43
5 Answers
Functions and tuples are rewritten as objects by the compiler, and only Function0
through Function22
and Tuple0
through Tuple22
are defined. I think the limit of 22 is entirely arbitrary, but the reason for having a limit is not.
Think of it this way: to run a Scala application the classes needed to run it must be present. If the compiler would dynamically create classes for functions then those classes would not be included in the Scala library JAR, so you would have to include them in your application. That could work, but then you would have the problem of what the classes' fully qualified names should be: if they were the same for all apps then you would have clashes since libraries would contain the same classes, and if the names were not the same you would end up with incompatibilities -- functions from libraries wouldn't be the same as functions in your app.

- 131,503
- 21
- 160
- 205
-
3It's actually Tuple1 through Tuple22, but that is just a minor detail. – Darian Lewin Mar 25 '14 at 09:58
-
10
-
2Still not very convinced as to why these classes shouldn't be dynamically generated by the compiler. The problem of naming and packaging could be resolved easily by following a naming convention. Not sure if I am missing the big picture. – Ankit Khettry Jun 27 '17 at 08:59
There is no such limit. Even if the standard libraries only define up to Function22, you can define Function23 if you need it, up to the JVM limit. Or you can group arguments into tuples. Or you could just stop pretending that any function takes more than one argument:
a => b => c => d => e => ...
Curried functions can take as many arguments as you want, up to the limit of your stack size.

- 34,834
- 8
- 106
- 155
It's mostly arbitrary, but there are some underlying limits on the JVM that dictate roughly what the limit needs to be.
The main issue is pattern-matching on case classes. If a case class allowed to be much bigger then the generated pattern-match code could very easily exceed the maximum valid method size. Everything else (Product, Function, Tuple, ...) just follows the 22-parameter limit that was therefore chosen for case classes.
Also... If you're writing functions/tuples with > 22 parameters then you're probably overdue for a redesign :)

- 49,540
- 9
- 105
- 155
-
21Sometimes it's not your design. Say you're writing a case class to represent a network protocol message that has more than 22 parameters. Or parsing a JSON response of a server you don't control. – Chad Dec 21 '13 at 00:07
-
Limit 22 has been dropped in dotty (Scala 3) by Drop function 22 limit #1758:
The limits of 22 for the maximal number of parameters of function types and the maximal number of fields in tuple types have been dropped.
Functions can now have an arbitrary number of parameters. Functions beyond
Function22
are erased to a new traitscala.FunctionXXL
and tuples beyondTuple22
are erased to a new traitscala.TupleXXL
. Both of these are implemented using arrays.
object drop22limit extends App {
val f23 = (x1: Int, x2: Int, x3: Int, x4: Int, x5: Int, x6: Int, x7: Int, x8: Int, x9: Int, x10: Int, x11: Int, x12: Int, x13: Int, x14: Int, x15: Int, x16: Int, x17: Int, x18: Int, x19: Int, x20: Int, x21: Int, x22: Int, x23: Int) => x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8 + x9 + x10 + x11 + x12 + x13 + x14 + x15 + x16 + x17 + x18 + x19 + x20 + x21 + x22 + x23
val result = f23(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23)
println(result)
}
outputs 276
. For examples of interplay between arbitrary arity tuples and functions see Add generalized tupled functions abstraction #6568

- 47,285
- 6
- 56
- 98
Arbitrary choice. Even though these classes are automatically generated, there must be a limit somewhere.
Note that you can have something like "tuples of arbitrary size" by using HLists or similar constructs (see http://jnordenberg.blogspot.com/2008/08/hlist-in-scala.html )

- 54,104
- 13
- 100
- 195