cast at call site problem (original) (raw)

Remi Forax forax at univ-mlv.fr
Thu Apr 4 00:27:32 PDT 2013

On 04/03/2013 08:50 PM, Dan Smith wrote:

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.

I try to think a way to avoid developers to know that there is a difference. A cast is something that the developer add explicitly, it's awkward if the type of the cast is not used.

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.

There is also the safe harbour which is to first test without using the cast type and if it fails, to re-try but using the type of the cast in the inference. It's always backward compatible but it makes the rules in the spec ugly.

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

Rémi

More information about the lambda-dev mailing list