diamond operator and non-denotable types

[Paul Benedict]

Maurizio,

Good response. Would you able to make the compiler's error diagnostic
verbose enough to emit an error such as:

"Construction with 'new Foo<>()' cannot determine type from
"Number&Comparator". Please use normal construction syntax."

This would help the user, like me, determine the possible types being expected.

Paul

On Mon, Apr 12, 2010 at 3:22 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Paul Benedict wrote:
>>>
>>> The compiler
>>> always erases an intersection type to the most appropriate type needed
>>> in order to preserve the semantics of the program.
>>>
>>
>> Maurizio,
>>
>> The diamond operator is supposed to be syntactic sugar, right? I don't
>> think the class file is the problem here; let the compiler collapse
>> the type as if you were not using the operator.
>>
>> Foo<?> f = new Foo<>();
>>
>> Just rewrite it like someone would write it in Java 5:
>> Foo<?> f = new Foo<X>();
>>
>
> Hi Paul,
> if the inference algorithm yields e.g. Foo<Number&Comparator<Number>>, how
> do you exactly go from this type to a type that the user would write? You'd
> have to choose between Number and Comparator<Number>, meaning that,
> depending on your choice, the members of one class or the other will be
> available for use --- which seems arbitrary, and not consistent with what we
> do with generic methods. Also consider that it's ot only about intersection
> types; there are also captured types which might be even harder to
> 'simplify' (e.g. do you propose to use the upper or lower bound? What if the
> bound is itself non-denotable?)
>
> However, if you decide to keep Foo<Number&Comparator<Number>> as is, you
> encounter a problem when you try to generate the classfile, in case the
> diamond operator is of the kind:
>
> new Foo<>() {} //anon class
>
> in fact, this generates a class of the kind:
>
> class Anon$Foo extends Foo<Number&Comparator<Number>> { ... }
>
> Which is rather weird --- in fact, there's no way to represent this in the
> classfile without extending the classfile format and the Signature attribute
> format, which is way outside the scope of the coin project.
>
> Back to your question; is diamond syntactic sugar? On the one hand yes; it
> provides a way to avoid the need of manually specifying type parameters on
> class instantiation. However there's a subtle point here: the set of types
> returned by the inference algorithm is larger than the set of types that can
> be used in a correct Java programs. What do we do in such cases?
>
> In my original email I suggested to reject the program (because it has no
> equivalent Java counterpart); on the other hand Neal would like to have the
> program accepted as long as this doesn't interfere with code generation;
> this means only rejecting the case of anonymous inner class creation.
>
> Maurizio
>
>> Paul
>>
>
>