cast at call site problem (original) (raw)

Dan Smith daniel.smith at oracle.com
Wed Apr 3 11:50:29 PDT 2013

On Apr 3, 2013, at 8:04 AM, Remi Forax <forax at univ-mlv.fr> wrote:

Note that a solution would have to deal with cases like:

(A) cond ? foo() : foo() yes, but it's not different from A a = cond ? foo(): foo()

and also with stuff like

(UnrelatedInterface) foo() The rules that are complex are the one between U and V when you have, U u = (V) ... and the implementation of javac was very wrong before you fix them. Back-propagating the type of V when doing the inference will not make these rules more complex, because you still require that the inferred return type of foo() to be compatible with V before trying to resolve the cast from V to U.

You're not acknowledging the difference between a casting context and an assignment/invocation context.

Casts can do narrowing. foo() could return Object, and the casts to both 'A' and 'V' would be legal.

I wouldn't say that we can never do anything clever here, but we have to recognize that a cast target inherently tells inference less than an invocation target. The implication is that you can probably always create scenarios in which an invocation target gets the "right" answer while a cast target does not.

BTW there is already a case where the cast is used to provide type information, it's when you use MethodHandle.invoke/invokeExact.

And lambdas/method refs, of course. Presumably both of these treat the cast as if it were an assignment context? I don't think that would fly for arbitrary method invocations.

—Dan

More information about the lambda-dev mailing list