Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8037788

15.12.2.5: Need to account for lambda bodies with no return expressions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 8
    • Fix Version/s: 8u40
    • Component/s: specification
    • Labels:

      Description

      A lambda expression like the following is compatible with any target return type.

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

      The more-specific rules compare return types "for each return expression". If there are 0 return expressions, as in this case, the conditions are vacuously satisfied, leading to surprising results:

      - One functional interface return type may be considered more specific than any other functional interface return type (regardless of, e.g., arity, void returns, nominal relationship, etc).

      - A primitive return type may be considered more specific than any reference return type.

      - A reference return type may be considered more specific than any primitive return type.

      The effect as that, in any of these circumstances, an ambiguity error occurs.

      Suggested text:
      ---
      R1 and R2 are functional interface types, ***there is at least one result expression,*** and R1 is more specific than R2 for each result expression.

      R1 is a primitive type, R2 is a reference type, ***there is at least one result expression,*** and each result expression is a standalone expression (15.2) of a primitive type.

      R1 is a reference type, R2 is a primitive type, ***there is at least one result expression,*** and each result expression is either a standalone expression of a reference type or a poly expression.
      ---

      The effect for primitive vs. reference return types is the same -- ambiguity -- but with a clearer explanation.

      The effect for two functional interface return types is that the nominal relationship between the two matters, but any structural relationship is ignored. This allows for fewer ambiguities when one functional interface type is a subtype of another.

      javac will need to be updated to match the different rules (it already fails to carefully match the quantifiers in the existing text, performing some tests at the top and some per-result-expression).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              abuckley Alex Buckley
              Reporter:
              dlsmith Dan Smith
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: