Question

并非我真的接近极限，但我一直想知道：为什么他们会停留在Function22 / Tuple22。 JVM限制？任意选择？

Answer 1

编译器将函数和元组重写为对象，并且仅定义Function0到Function22和Tuple0到Tuple22。我认为22的限制完全是任意的，但限制的原因不是。

以这种方式思考：要运行Scala应用程序，必须存在运行它所需的类。如果编译器会动态创建函数类，那么这些类将不会包含在Scala库JAR中，因此您必须将它们包含在应用程序中。这可能有用，但是你会遇到类的完全限定名称应该是什么问题：如果它们对于所有应用程序都是相同的那么你会发生冲突，因为库将包含相同的类，如果名称不是同样，最终会出现不兼容问题 - 库中的函数与应用程序中的函数不同。

Answer 2

没有这样的限制。即使标准库仅定义了Function22，您也可以根据需要定义Function23，最高可达JVM限制。或者您可以将参数分组为元组。或者你可以停止假装任何函数需要多个参数：

a => b => c => d => e => ...

Curried函数可以根据需要使用尽可能多的参数，直到堆栈大小的限制。

Answer 3

它几乎是随意的，但是在JVM上有一些潜在的限制，大致规定了限制需要的限制。

主要问题是案例类的模式匹配。如果允许案例类大得多，则生成的模式匹配代码可能很容易超过最大有效方法大小。其他一切（产品，功能，元组，......）只是遵循因为案例类选择的22参数限制。

另外......如果您正在使用＆gt;编写函数/元组。 22个参数然后你可能已经过期了重新设计：）

Answer 4

限制22已被dropped限制为Drop function 22 limit #1758的点数（Scala 3）：

函数参数的最大数量限制为22 类型和元组类型中最大字段数为放下。

函数现在可以具有任意数量的参数。职能超出Function22的部分将被擦除为新特性scala.FunctionXXL， Tuple22之后的元组将被擦除为新特征scala.TupleXXL。都这些都是使用数组实现的。

For example,

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

输出276。有关任意Arity元组和函数之间相互作用的示例，请参见Add generalized tupled functions abstraction #6568

Answer 5

任意选择。即使这些类是自动生成的，也必须有某个限制。

请注意，您可以使用HLists或类似结构来获得类似“任意大小的元组”的内容（请参阅http://jnordenberg.blogspot.com/2008/08/hlist-in-scala.html）

为什么scala函数限制为22个参数？

5 个答案: