diamond operator and non-denotable types

[Paul Benedict]

I think the message is clear from the technical sense, but may I
suggest an improvement? I do not believe most programmers would
understand "denotable type" or "intersection type" and I would like to
see an alternative wording.

Paul

On Tue, Apr 13, 2010 at 7:49 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Paul Benedict wrote:
>>
>> 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."
>>
>
> Hi Paul,
> the error message that is currently generated is something like:
>
> TestX.java:4: cannot infer a denotable type argument for Foo<>;
> Foo<?> f = new Foo<>() {};
>                 ^
>  reason: type argument INT#1 inferred for Foo<> is not denotable
>  where INT#1 is an intersection type:
>   INT#1 extends Number,Comparator<Number>
> 1 error
>
> The error message is taking advantage of the improved diagnostic support ---
> the intersection type is explicitly described in a 'where' clause generated
> by the compiler, listing all the upper bounds of the type.
>
> Maurizio
>
>> 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
>>>>
>>>>
>>>
>>>
>
>