为什么 Scala 标准库中 @specialized 的东西这么少？

Question

我在Scala 2.8.1标准库的源代码中搜索了@specialized的使用。看起来只有少数特征和类使用此注释：Function0、Function1、Function2、Tuple1、 Tuple2、Product1、Product2、AbstractFunction0、AbstractFunction1、AbstractFunction2< /代码>。

没有一个集合类是@specialized。为什么不呢？这会产生太多的类吗？

这意味着使用具有原始类型的集合类是非常低效的，因为会发生很多不必要的装箱和拆箱。

拥有 Int 的不可变列表或序列（具有 IndexedSeq 特征），避免装箱和拆箱的最有效方法是什么？

Answer 1

专业化对班级规模的成本很高，因此必须慎重考虑。就收藏的具体情况而言，我想影响将会是巨大的。

尽管如此，这仍然是一项持续的努力——Scala 库才刚刚开始专业化。

Answer 2

专业化在类的大小和编译时间方面都可能是昂贵的（指数）。它不仅仅是像接受的答案所说的大小。

打开你的 scala REPL 并输入以下内容。

import scala.{specialized => sp}
trait S1[@sp A, @sp B, @sp C, @sp D] { def f(p1:A): Unit }

对不起 ：-）。它就像一个编译器炸弹。

现在，让我们采用一个简单的特征

trait Foo[Int]{ }

上面将产生两个编译的类。 Foo，纯接口和 Foo$1，类实现。

现在，

trait Foo[@specialized A] { }

这里的专用模板参数被扩展/重写为 9 种不同的基本类型（ void、boolean、byte、char、int、long、short、double、float）。因此，基本上您最终会得到 20 个类，而不是 2 个。

回到具有 5 个专用模板参数的特征，为可能的原始类型的每种组合生成类。即其复杂性呈指数级增长。

2 * 10 ^ ^{（没有专用参数）}

如果您正在为特定的原始类型定义一个类，则应该更明确地说明它，例如

trait Foo[@specialized(Int) A, @specialized(Int,Double) B] { }

可以理解，在构建通用目的时必须节俭使用专用图书馆。

这里是 Paul Phillips 对此的咆哮。

Answer 3

我自己的问题的部分答案：我可以将数组包装在 IndexedSeq 中，如下所示：（

import scala.collection.immutable.IndexedSeq

def arrayToIndexedSeq[@specialized(Int) T](array: Array[T]): IndexedSeq[T] = new IndexedSeq[T] {
  def apply(idx: Int): T = array(idx)
  def length: Int = array.length
}

当然，如果您有权访问底层数组，您仍然可以修改内容，但我会确保该数组没有传递到我的程序的其他部分）。