[enhanced-enums]: Enhanced enums failure with raw types?
maurizio.cimadamore at oracle.com
Mon Sep 18 20:09:21 UTC 2017
On 18/09/17 19:59, B. Blaser wrote:
> On 18 September 2017 at 16:28, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> In any case, changing the compiler behavior in this area is a big change,
>> and should be considered carefully, and as part of a more holistic effort to
>> bring the compiler in sync with the spec.
> I agree with you.
> And while our example might be related to JDK-8026527, I think it
> looks more like JDK-7177306.
Sorry, I don't see the connection
> Which also means that javac's current behavior with
> "EnumSet<G<Object>> g3 = EnumSet.allOf(G.class)" would be compliant
> with the JLS 9:
> * according to §18.104.22.168, "G" being raw, the constraint < EnumSet ->
> EnumSet<G<Object>> > is incorporated.
You keep talking about 22.214.171.124 - but I don't think that's the place
where the action happens. You just need 18.5.1 e.g. inference in
overload resolution. The sole constraint (coming from the actual) that
Class<G> <: Class<E> is enough to create problems. We are not even
looking at the target type here - concluding that G = E, and then
verifying that G satisfies E's declared bound (which you have to do, as
18.5.1 does incorporation too) is enough to stress the dependency on
unchecked conversion during incorporation.
I don't see anything in incorporation that gives special unchecked
treatment to a check like this:
G <: Enum<E>
The only thing I can find is this, in section 18.2.3 (subtyping
constraints) - given S <: T...
"If T is a parameterized class or interface type, or an inner class type
of a parameterized class or interface type (directly or indirectly), let
A_1 , ..., A_n be the type arguments of T. Among the supertypes of S, a
corresponding class or interface type is identified, with type arguments
B_1 , ..., B_n . If no such type exists, the constraint reduces to
/false/. Otherwise, the constraint reduces to the following new
constraints: for all /i/ (1 ≤ /i/ ≤ /n/), ‹B_i |<=| A_i ›."
Now, since S is raw here, there's no supertype of S for which we can
derive the type-arguments that should be used to set up the equality
constraints. So I think that means incorporation returns false here (and
the method is then considered not applicable, as per 18.5.1).
> * then "EnumSet" have to be compatible in a loose invocation context
> with "EnumSet<G<Object>>" (§18.1.2).
> * and in such a case (§5.3), an unchecked conversion may then be applied.
> The compiler should then emit an unchecked warning and succeed.
> So, I think that the current behavior looks correct in our example
> even if some non-conformance issues still remain, as you mentioned.
> Do we agree with this temporary conclusion?
More information about the amber-dev