[enhanced-enums]: Enhanced enums failure with raw types?

[Maurizio Cimadamore]

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.5.2.1, "G" being raw, the constraint < EnumSet ->
> EnumSet<G<Object>> > is incorporated.
You keep talking about 15.12.2.1 - 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).

Maurizio
> * 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?
>
> Bernard
>
>> Maurizio