Incoherent invocation type inference?

[B. Blaser]

Hi,

2017-01-15 22:44 GMT+01:00 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
>
>> The problem of the code of Bernard is not related to the inference, the
>> problem is the unsafe cast in the implementation, if you use an unsafe cast,
>> then you may have a ClassCastException at runtime. It's as simple as that.
>
> Of course that's the problem :-)
>
> I was speculating as to whether there could be something the compiler could
> do to help out programmers setting right expectations for a given generic
> method signature, as I've seen this problem (unchecked issues mistaken for
> inference issues) coming up frequently.
>
> Maurizio

The problem I see in our example is that:

- if we had a method "Iterable get()", "i=get()" won't be possible
unless an existing "class C extends Integer implements Iterable"
exists; and in such a case we had to cast explicitly "i=(C)get()".
- but with "<T extends Iterable> T get()", javac infers T to an
hypothetical intersection type without knowing if such a type exists
or could even exist (no, in the case of a final class).

So, I suggest a general "lint" warning if javac infers T to an
intersection type, because T is widened without being sure that it is
possible; this would be cohernent with the "lint" warning for the
unchecked cast "(T)" in "get()".

What do you think of such a rule?

Thanks,
Bernard