invocation type of method reference declaration

Rafkind, Jon jon.rafkind at
Thu Feb 13 17:39:57 PST 2014

On 02/13/2014 04:31 PM, Dan Smith wrote:

On Feb 12, 2014, at 6:00 PM, Rafkind, Jon <jon.rafkind at><mailto:jon.rafkind at> wrote:

What is the invocation type of the compile-time chosen method
declaration of a method reference?

In section 15.3.2:
The return type of the function type is R; the result of applying
capture conversion (5.1.10) to the return type of the invocation type
( of the chosen declaration is R', where R is the target type
that may be used to infer R'; neither R nor R' is void; and R' is
compatible with R in an assignment context.

Also in section
Otherwise, let R be the return type of the function type, and let R' be
the result of applying capture conversion (5.1.10) to the return type of
the invocation type ( of the chosen declaration. If R' is
void, the constraint reduces to false; otherwise, the constraint reduces
to ⟨R' → R⟩.

A method reference is not the same as a method invocation so
don't seem to apply. Are the parameters of the function type supposed to
act as the types of the argument expressions to the compile-time

There is admittedly a degree of informality here (consistent with the style of the rest of JLS), but I'm not seeing any particular points that need clarification.  (Feel free to point them out if you think I'm missing something.)

The following terms are a bit fuzzy, but have only one reasonable interpretation:

- The "explicit type arguments" of the "method invocation".  Of course this refers to the type arguments of the method reference, a pattern already established in 15.13.1.

- Whether "unchecked conversion was necessary for the method to be applicable".  The applicability test is as described in, as applied from 15.13.1.

- The "type that was searched" is defined in 15.13.1.

- During inference, we need to know whether "the invocation is a poly expression" (18.5.2).  This is probably the least well-defined.  The rules for whether a method invocation is a poly expression are in 15.12; analogous rules can be applied to the method reference in order to decide whether that particular branch in 18.5.2 should be pursued or not (specifically: the method reference does not have type arguments, the compile-time declaration is generic, and the return type of the compile-time declaration mentions one of its type parameters).

I'll create a bug to clarify that last point in the future.


Ok, that helps. I see how invocation types for method invocations can be applied to method references.

When determining set B3 for a method references in what are the expressions supposed to be replaced with when computing set B2 in 18.5.2. That is, B2 is defined as the bound set computed during 18.5.1 and 18.5.1 says " Let F1, ..., Fn be the types of the formal parameters of m, and let e1, ..., ek be the actual argument expressions of the invocation." Should e1...ek be replaced with the types of the arguments of the functional type?

Also, in 18.5.2 the third case says "If the invocation is a poly expression, let R be the return type of m, and let T be the invocation's target type". Should "invocation's target type" be replaced with "type of the invocation expression" so that the return type of the method declaration can be related to the return type of the functional type. Otherwise it would try to relate the return type of the method declaration with the functional type's method type. This matches the text in

The type of the method invocation expression is obtained by applying capture conversion (5.1.10<>) to the return type of the invocation type of the chosen method.

For example,

reference = HashMap::new
functional type = java.util.function.Supplier<M>
compile-time declaration of reference = HashMap<K, V> constructor()
formula = {HashMap<K, V> -> M}

(ignoring theta, of course)

More information about the lambda-spec-observers mailing list