Type Inference Question
Jan Finis
jpfinis at gmail.com
Wed May 30 08:14:23 PDT 2012
Thank you very much for your comments,
On 05/30/2012 04:38 PM, Maurizio Cimadamore wrote:
>
>
> I'll leave the spec-related discussion to our spec gurus - but javac
> infers List<String> in such cases (i.e. no wildcard), as can be
> demonstrated by the following example: class Test {
> <Z> Z m(Z z) { return null; }
> void test(java.util.List<String> ls) {
> ls = m(ls); //ok!
> }
> }
>
I don't understand this one. This example compiles fine with my compiler
(which strictly adheres to the spec and calls lub(List<String>) which
results in List<String> in my implemention ). I also get no wildcards here.
On 05/30/2012 04:38 PM, Maurizio Cimadamore wrote:
>
> Javac workarounds the problem by using the capture of the upper bound
> of an argument type during method checking. This allows inference to
> infer less captured types, which, at the time the javac implementation
> with generics was rolled out, it was believed to be better in terms of
> usability.
Can you try to explain that in more detail? I have tried to replace
captured types by their upper bounds, which makes my example compile:
keySet = UnmodifiableMap.unmodifiableSet(m.keySet()); //Now, the upper
bound of "Capture of ? extends K" is used, which is K, and everything
compiles fine
However, the standard example from the spec does not compile then:
public class captureConversion {
public static void reverse(List<?> list) {
rev(list);
}
private static <T> void rev(List<T> list) {
List<T> tmp = new ArrayList<T>();
for (int i = 0; i < list.size(); i++) {
list.set(i, tmp.get(list.size() - i - 1));
}
}
}
Here, the compiler correctly infers "Capture of ?" as type of T. If I
would infer the upper bound of that type, which is Object, then the
method would not compile because I cannot hand a List<?> to a method
wanting a List<Object>.
By the way: Do I have to create a new capture type whenever capture
conversion is performed? I currently do it, but it creates quite some
capture types which are only used during the checking of single
expressions (because the next expression receives a new capture, even if
the captured argument was already captured before). It seems like the
eclipse jdt compiler does that, since its enumerats the captures. Having
ten expressions with capture conversion results in "Capture #1 of ..."
up to Capture #10 of ...".
Is the type inference part of javac open source? If so, can you give me
a hint where I can find it? The code might make many things clearer...
Best regards and thanks again for your help,
Jan Finis
More information about the compiler-dev
mailing list