“数组初始化程序需要显式目标类型” - 为什么？ [英] "array initializer needs an explicit target-type" - why?

问题描述

以下 JEP 286：本地变量类型推断说明

我想知道，引入这种限制的原因是：

I am wondering, what the reason is for introducing such a restriction, as:

Main.java:199: error: cannot infer type for local variable k

    var k = { 1 , 2 };
        ^   
(array initializer needs an explicit target-type)

所以对我来说逻辑上它应该是：

So for me logically it should be:

var k = {1, 2}; // Infers int[]
var l = {1, 2L, 3}; // Infers long[]

因为Java编译器可以已经正确推断出数组的类型：

Because Java compiler can already infer properly the type of an array:

void decide() {
    arr(1, 2, 3);  // call  void arr(int ...arr)
    arr(1, 2L, 3); // call  void arr(long ...arr)
}

void arr(int ...arr) {
}

void arr(long ...arr) {
}

那么障碍是什么？

推荐答案

每次我们改进Java中类型推断的范围时，我们都会得到一连串但你也可以推断出这一点，为什么不是吗？ （或者有时候，不太礼貌。）

Every time we improve the reach of type inference in Java, we get a spate of "but you could also infer this too, why don't you?" (Or sometimes, less politely.)

关于设计类型推断方案的一些一般性观察：

Some general observations on designing type inference schemes:

• 推理方案总是有限制的;在边缘总是存在我们无法推断答案，或最终推断出令人惊讶的事情的情况。我们越努力推断一切，我们越有可能推断出令人惊讶的事情。这并不总是最好的权衡。


• 很容易挑选出但在这种情况下你可以推断出来的例子。但是，如果这种情况与其他没有明显答案的案例非常相似，我们只是将问题转移到了 - 为什么它适用于X而不是Y，其中X和Y都是Z？


• 总是可以使用推理方案来处理增量案例，但几乎总是存在附带损害，或者是在其他情况下获得更差的结果，增加的不稳定性（在看似无关的地方）更改可以更改推断类型），或更复杂。您不希望仅根据您可以推断的案例数进行优化;您还希望优化受过教育的用户预测哪些有效，哪些无效。绘制更简单的行（例如，不要试图推断数组初始化器的类型）通常在这里是一个胜利。


• 鉴于总有限制，通常最好选择较小但定义较好的目标，因为这样可以简化用户模型。 （参见相关问题为什么我不能对私有方法的返回类型使用类型推断。答案是我们可以做到这一点，但结果将是一个更复杂的用户模型，用于表达小的利益。我们称之为复杂性很差。）

• Inference schemes will always have limits; there are always cases at the margin where we cannot infer an answer, or end up inferring something surprising. The harder we try to infer everything, the more likely we will infer surprising things. This is not always the best tradeoff.
• It's easy to cherry-pick examples of "but surely you can infer in this case." But if such cases are very similar to other cases that do not have an obvious answer, we've just moved the problem around -- "why does it work for X but not Y where X and Y are both Z?"
• An inference scheme can always be made to handle incremental cases, but there is almost always collateral damage, either in the form of getting a worse result in other cases, increased instability (where seemingly unrelated changes can change the inferred type), or more complexity. You don't want to optimize just for number of cases you can infer; you want to optimize also for an educated user's ability to predict what will work and what will not. Drawing simpler lines (e.g., don't bother to try to infer the type of array initializers) often is a win here.
• Given that there are always limits, its often better to choose a smaller but better-defined target, because that simplifies the user model. (See related questions on "why can't I use type inference for the return type of private methods. The answer is we could have done this, but the result would be a more complicated user model for small expressive benefit. We call this "poor return-on-complexity.")

这篇关于“数组初始化程序需要显式目标类型” - 为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！