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

[B. Blaser]

On 11 September 2017 at 22:38, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> On 11/09/17 20:25, B. Blaser wrote:
>>
>> What do you think of this way of representing heterogeneous options?
>
> I'm not convinced it works? In your example you have:
>
>         EnumSet<G<Object>> g3 = EnumSet.allOf(G.class);
>
>
> So, while it's true that the LHS is now well-formed, I think inference would
> still fail - as you get one equality constraint like this:
>
> E = G<Object> (from LHS)
>
> but another constraint is like this
>
> E = G (from actual argument, whose type is Class<G> - raw type parameter)
>
> And these two constraints are incompatible. You'd probably need to throw in
> a cast near G.class.

I agree with you, but this works with a warning (with the latest
"enhanced enums" version - I've not tried with the JDK 9).

It seems the inference occurs only on the actual argument (E = G) and
then an unchecked cast is made from "EnumSet<G>" to
"EnumSet<G<Object>>" when returning a value, producing a warning.

(Or the inverse - I've not verified - inference from the return type
(E = G<Object>) and unchecked cast from "Class<G>" to
"Class<G<Object>>" when passing the actual argument)

Is this a bug?

> That said, even looking at the LHS, using Object (or any other 'ground' type
> that happens to be compatible with how the enum is used) works, but only
> until there's no bound in the enum declaration. If there's a bound, and the
> bound is a ground type you are still ok - as you can use that instead of
> Object, but if the bound is an f-bound, then I think you are out of luck.

I think you're right.

But we could probably avoid those situations with some casts or
eventually with the help of interfaces and other kinds of sets (not
EnumSet).

I just saw that when simply adding a type variable on javac options
("Option<X>"), we get only one error which can be solved with some
casts.

All the rest are warnings which could probably also be avoided with
casts, interfaces and other kinds of sets.

Note that this is inevitable with heterogeneous collections, the same
thing would happen with collections of heterogeneous classes...

But this would be probably better than working only on "String"
options which neither produce any warning nor need any cast but
unfortunately aren't safer (and obviously less expressive).

And, at my mind, only sharper typing could be useful enough to
rehabilitate enhanced enums...

Bernard

> Maurizio