cast at call site problem

[Dan Smith]

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