cast at call site problem

Remi Forax forax at
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> 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


More information about the lambda-dev mailing list