Лямбда-выражение и метод перегружают сомнения

Я думаю, вы нашли эту ошибку в компиляторе: JDK-8029718 (или аналогичный в Eclipse: 434642).

Сравните с JLS §15.12.2.1. . Определите потенциально применимые методы:

…

• Лямбда-выражение (§15.27) потенциально совместимо с типом функционального интерфейса (§9.8), если выполняются все следующие условия:

  • Арность типа функции целевого типа такая же, как и арность лямбда-выражения.

  • Если тип функции целевого типа имеет возврат void, то тело лямбда-выражения является либо выражением инструкции (§14.8), либо блоком, совместимым с void (§15.27.2).

  • Если тип функции целевого типа имеет возвращаемый тип (не пустой), то тело лямбда-выражения является либо выражением, либо блоком, совместимым со значением (§15.27.2).

Обратите внимание на четкое различие между «void совместимыми блоками» и «блоками, совместимыми по значению». Хотя в некоторых случаях блок может быть и тем и другим, раздел §15.27.2. В Lambda Body четко указано, что такое выражение, как () -> {}, является «void совместимым блоком», так как обычно завершается без возврата значения. И должно быть очевидно, что i -> {} также является «void совместимым блоком».

И, согласно приведенному выше разделу, комбинация лямбда-выражения с блоком, несовместимым по значению, и целевой тип с возвращаемым типом (не-void) не является потенциальным кандидатом на разрешение перегрузки метода. Так что ваша интуиция верна, здесь не должно быть никакой двусмысленности.

Примеры неоднозначных блоков:

() -> { throw new RuntimeException(); }
() -> { while (true); }

так как они нормально не завершаются, но в вашем вопросе это не так.

Об этой ошибке уже сообщалось в системе ошибок JDK: https://bugs.openjdk.java.net/browse/JDK-8029718. Как вы можете убедиться, ошибка была исправлена. Это исправление синхронизирует javac со спецификацией в этом аспекте. Прямо сейчас javac правильно принимает версию с неявными лямбда-выражениями. Чтобы получить это обновление, необходимо клонировать репозиторий javac 8.

Что делает исправление, так это анализирует тело лямбда и определяет, совместимо ли оно с пустотой или значением. Чтобы определить это, вам необходимо проанализировать все операторы возврата. Давайте вспомним, что из спецификации (15.27.2), уже упомянутой выше:

• Тело лямбда-выражения блока совместимо с void, если каждый оператор return в блоке имеет форму return.
• Тело лямбда-выражения блока совместимо по значению, если оно не может завершиться нормально (14.21), и каждый оператор return в блоке имеет форму return Expression.

Это означает, что, анализируя возвраты в теле лямбда, вы можете узнать, совместимо ли тело лямбда с пустотой, но чтобы определить, совместимо ли оно по значению, вам также необходимо выполнить анализ потока, чтобы определить, может ли оно выполняться нормально (14.21).

Это исправление также вводит новую ошибку компилятора для случаев, когда тело не является ни пустым, ни совместимым по значению, например, если мы скомпилируем этот код:

class Test {
    interface I {
        String f(String x);
    }

    static void foo(I i) {}

    void m() {
        foo((x) -> {
            if (x == null) {
                return;
            } else {
                return x;
            }
        });
    }
}

компилятор выдаст такой вывод:

Test.java:9: error: lambda body is neither value nor void compatible
    foo((x) -> {
        ^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

Надеюсь, это поможет.

Предположим, у нас есть метод и вызов метода

void run(Function<Integer, Integer> f)

run(i->i)

Какие методы мы можем легально добавить?

void run(BiFunction<Integer, Integer, Integer> f)
void run(Supplier<Integer> f)

Здесь арность параметра другая, в частности, i-> часть i->i не соответствует параметрам apply(T,U) в BiFunction или get() в Supplier. Так что здесь любые возможные неоднозначности определяются арностью параметра, а не типами и не возвратом.

Какие методы мы не можем добавить?

void run(Function<Integer, String> f)

Это дает ошибку компилятора как run(..) and run(..) have the same erasure. Так как JVM не может поддерживать две функции с одинаковыми именами и типами аргументов, это невозможно скомпилировать. Таким образом, компилятору никогда не приходится разрешать неоднозначности в этом типе сценария, поскольку они явно запрещены из-за правил, ранее существовавших в системе типов Java.

Таким образом, у нас остаются другие функциональные типы с арностью параметра, равной 1.

void run(IntUnaryOperator f)

Здесь run(i->i) допустимо как для Function, так и для IntUnaryOperator, но это не будет компилироваться из-за reference to run is ambiguous, так как обе функции соответствуют этой лямбде. На самом деле они это делают, и здесь следует ожидать ошибки.

interface X { void thing();}
interface Y { String thing();}

void run(Function<Y,String> f)
void run(Consumer<X> f)
run(i->i.thing())

Здесь это не скомпилируется, опять же из-за двусмысленности. Не зная типа i в этой лямбде, невозможно узнать тип i.thing(). Поэтому мы признаем, что это неоднозначно и правильно не компилируется.

В вашем примере:

void run(Consumer<Integer> f)
void run(Function<Integer,Integer> f)
run(i->i)

Здесь мы знаем, что оба функциональных типа имеют один параметр Integer, поэтому мы знаем, что i в i-> должно быть Integer. Итак, мы знаем, что должно быть вызвано run(Function). Но компилятор не пытается это сделать. Это первый раз, когда компилятор делает что-то, чего мы не ожидаем.

Почему это не делается? Я бы сказал, потому что это очень специфический случай, и вывод типа здесь требует механизмов, которых мы не видели ни в одном из других вышеперечисленных случаев, потому что в общем случае они не могут правильно определить тип и выбрать правильный метод. .