on diamond and evolution

[Stephen Colebourne]

All,
I just wanted to express thanks that the time and effort has been taken 
to work through this difficult issue from all parties. Its great to see 
it come to a clear and positive resolution. I believe that the Java 
platform has benefitted as a result.
Stephen


Neal Gafter wrote:
> Maurizio-
> 
> I think this is the right tradeoff: a slight loss of functionality in the
> short term to enable further improvements later.
> 
> Cheers,
> Neal
> 
> On Fri, Nov 6, 2009 at 3:31 AM, Maurizio Cimadamore <
> Maurizio.Cimadamore at sun.com> wrote:
> 
>> Hi
>> Following the recent discussions in this mailing list about the diamond
>> implementation, I decided to spent some more time in order to figure
>> out  exactly what it means, in term of language evolution, supporting
>> the simple approach currently checked in the JDK 7 repository.
>>
>> Quick recap:
>>
>> *) Simple approach: infers the diamond type using the *only* the
>> expected type (if available) - similar (if not identical) to 15.12.2.8
>>
>> *) Complex approach: infers the diamond type using a full inference
>> round (arguments + return type) - 15.12.2.7 + 15.12.2.8
>>
>> *) Full-complex approach: an hypothetical approach that is based upon
>> complex (see above) - in addition, it throws the constraint about the
>> expected type earlier in the inference process (precisely in 15.12.2.7),
>> so that argument type inference cannot infer a type that, by being too
>> specific, is incompatible with the expected type.
>>
>> As it was shown in [1] there is no subset relationship between simple
>> and complex - that is the two inference routines simply yield different
>> results - in this sense, the simple approach cannot be viewed as a
>> proper subset of the complex approach.
>>
>> This is bad for evolution, as pointed out by Neal. My argument was that
>> there existed a full-complex approach capable of subsuming both simple
>> and complex at the same time - this would have allowed for further
>> language extension (e.g. argument type inference) w/o breaking
>> compatibility.
>>
>> After a more detailed analysis I found out that the full-complex
>> approach, while feasible is not fully backward compatible with the
>> simple approach. The full-complex works nicely when the attribution
>> context has an expected type (because the type inferred for diamond is
>> compatible with the types inferred by both approaches). However, when
>> the attribution context is missing an expected type, things don't go as
>> planned. Here's a simple example:
>>
>> class Foo<X> {
>>  Foo<X>(X x) {}
>>  Foo<X> get() { return this; }
>> }
>>
>> Foo<Object> = new Foo<>(1).get();
>>
>> With the simple approach this works just fine. The argument type is
>> never considered during inference - because of that, diamond ends up
>> inferring Object (the bound of X) for X. Calling get() on a Foo<Object>
>> yields a Foo<Object> which is compatible with the LHS type in the
>> assignment.
>>
>> Now suppose that in some release >7 we enable the full-complex approach.
>> What would happen to this particular example? When a type is to be
>> inferred for Foo<>, both argument and expected type are considered. Here
>> there's no expected type (the LHS type of the assignment is the expected
>> type for the get() call) - so full-complex is roughly equivalent to
>> existing 15.12.2.7. Which (again) would yield a different type than the
>> one returned by the simple approach - namely Foo<Integer> instead of
>> Foo<Object>. Now, calling get() on Foo<Integer> would yield Foo<Integer>
>> which is clearly incompatible with Foo<Object>. Btw: I'm not saying that
>> accepting the above code is a must - an inference scheme can either
>> accept (as simple) that or reject that (as complex); however, if we now
>> choose a scheme that allows it, future releases will also have to cope
>> with that, and we have seen clearly that even the full-complex approach
>> cannot guarantee that.
>>
>> Bottom line: the full-complex approach doesn't represent a viable
>> alternative for reconciling the diamond inference routine with the
>> standard javac's method inference routine - as a result, the simple
>> approach currently implemented in the JDK7 would represent an obstacle
>> for future language extensions. In principle, it would be possible to
>> limit the scope of the simple approach to those contexts that have an
>> expected type, so that the simple approach would fail when no expected
>> type is given. While this is clearly a forward compatible solution, we
>> believe it would be unnecessarily restrictive and ultimately not worth
>> pursuing it.
>>
>> Recalling from my earlier emails, the biggest disadvantage of the
>> complex approach vs. simple is the following example:
>>
>> Foo<Object> foo =  new  Foo<>(1);
>>
>> However I believe this can eventually be fixed by an inference overhaul
>> on the lines of the full-complex approach, so that the argument type
>> inference would take into account the expected return type (thus
>> inferring Object instead of Integer). Actually, that's also the biggest
>> advantage of the complex approach: any change that will positively
>> affect javac's standard type-inference, will positively affect diamond
>> as a side-effect.
>>
>> The next obvious step is to simply switch the diamond implementation in
>> the jdk 7 repository, as we already have a working prototype (see [2]).
>>
>> Thanks to everyone for participating in the discussion and helping in
>> making Java a better language.
>> Maurizio
>>
>> [1] -
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html
>> [2] - http://cr.openjdk.java.net/~mcimadamore/6840638/webrev.1/<http://cr.openjdk.java.net/%7Emcimadamore/6840638/webrev.1/>
>>
>>
>>
> 
>