为什么Java8的toIntFunction不扩展函数

Question

如果我编写了ToIntFunction接口，我希望在接口中编码这样一个事实，即它只是一个返回原始int的函数，如下所示：

@FunctionalInterface
public interface ToIntFunction<T> extends Function<T, Integer> {
    int applyAsInt(T value);

    @Override
    default Integer apply(T value) {
        return Integer.valueOf(applyAsInt(value));
    }
}

我想知道，Java8 API设计者选择将原始的替代方案与函数完全分离，是不是有一个令人信服的原因？是否有证据显示他们曾考虑这样做，并决定不这样做？我想类似的问题至少也会出现在其他一些“特殊”功能接口上，比如Consumer（可能是function )和Supplier（function )。

我还没有对这件事的所有后果进行深入和彻底的思考，所以我可能遗漏了一些东西。

如果ToIntFunction（和其他基本的泛型函数接口）与Function有这种关系，那么就可以在需要Function参数的地方使用它（想到的是与其他函数的组合，例如调用MyFunction.compose（myIntFunction）或者避免在API中编写几个专门的函数，而如上所述的自动（取消）装箱实现就足够了）。

这与这个问题非常相似：为什么Java8的谓词 不扩展函数 但我已经意识到，由于语义原因，答案可能不同。因此，我重新表述了这个问题，它是函数的一个简单的原语替代，在这里不可能有任何语义，只有原语和包装类型，甚至可以消除包装对象为空的可能性。

Answer 1

JDK8中的接口爆炸是Java中一个小问题的产物：值类型的缺乏。

这意味着我们不能将基元类型与泛型一起使用，因此，我们被迫使用包装类型。

换句话说，这是不可能的：

Function<String, int> myFunction;

Function<String, Integer> myFunction;

这样做的问题是装箱/取消装箱。这可能会变得昂贵，并使处理基元数据类型的算法难以优化，因为经常需要为基元值创建包装对象，反之亦然。

这就解释了为什么JDK 8中的接口激增，比如function和intfunction，后者使用基元类型作为参数。

在Lambda邮件列表中的某个时候讨论了这一点，表明专家组正在为此苦苦挣扎。

lambda项目的规范负责人Brian Goetz在那里写道：

更普遍地说：拥有专门的原始流（例如，IntStream)背后的哲学充满了令人讨厌的权衡。一方面，这是大量丑陋的代码重复，接口污染等。另一方面，任何一种在盒形操作上的算术都是糟糕的，没有故事来减少超过int将是可怕的。所以我们现在处境艰难，我们不想让情况变得更糟。

不让它变得更糟的第一个诀窍是：我们没有做所有的八个原始类型。我们在做int,long和double；所有其他的都可以用这些来模拟。可以说，我们也可以摆脱int，但我们认为大多数Java开发人员还没有做好准备。是的，会有字符的调用，答案是“把它贴在int中。”（每个专门化都被投影到约100K的JRE占用空间。）

诀窍2是：我们使用原语流来公开在原语域中最好完成的事情（排序、约简），而不是试图复制在装箱域中可以完成的一切。例如，Aleksey指出，没有intStream.into（）。（如果有的话，下一个问题是“IntCollection在哪里？IntArrayList在哪里？IntConcurrentSkipListMap在哪里？）目的是许多流可以作为引用流开始，以基元流结束，反之亦然。这是可以的，并且减少了所需转换的数量（例如，对于int->T，不重载映射，对于int->T不专门化函数，等等）

很可能，将来当我们在Java中获得对值类型的支持时，我们将能够摆脱（或者至少不再需要使用）这些接口。

专家组纠结于几个设计问题，不仅仅是这个。保持向下兼容的需要、要求或约束使事情变得困难，然后我们就有了其他重要的条件，如缺少值类型、类型擦除和检查异常。如果Java有第一个而没有其他两个，那么JDK8的设计就会非常不同。因此，我们都必须明白，这是一个难题，有很多权衡，而EG必须在某处划出界线，并作出决定。