cast at call site problem
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.
More information about the lambda-dev