Spec draft for JEP 286 Local Variable Type Inference

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Dan Smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 30 Mars 2017 18:53:30
> Objet: Re: Spec draft for JEP 286 Local Variable Type Inference

>> On Mar 29, 2017, at 5:58 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Dan,
>> Looks great !
>> 
>> In 14.4.1, a minor remark, i had to look for what standalone expression is, not
>> poly expression seems better for me so i suggest that
>>  Because the initializer is a standalone expression, an error occurs if it is a
>>  lambda expression (15.27) or a method reference expression (15.13).
>> can be
>>  Because the initializer is not a poly expression, an error occurs if it is a
>>  lambda expression (15.27) or a method reference expression (15.13).
> 
> Thanks for raising this. I don't like either "is a standalone expression" or "is
> not a poly expression", because lambda expressions are *always* poly
> expressions. I guess what I want to say is this:
> 
> "Because the initializer is treated as if it did not appear in an assignment
> context, an error occurs if it is a lambda expression or a method reference
> expression."

yes, better.

> 
>> So a var initialized by an anonymous class with diamond is not supported because
>> it's not a poly expression (but its type is denotable) and
>> an anonymous class with type arguments is not supported because its type is not
>> denotable.
> 
> No. There is not a requirement that diamond class instance creation expressions
> (for anonymous classes or otherwise) be poly expressions. It's perfectly fine
> to use one of these in a context that has no target type.

Ok, my bad, an expression can be right hand side context sensitive without being a poly expression.

> 
>> Given that without var, when the type of an anonymous class with a diamond is
>> inferred, the resulting type is the super type,
>> i think you can relax the current rule to allow var to be initialized with an
>> anonymous class (with no diamond), the resulting type will be the super type.
> 
> I'll have more to say about the treatment of non-denoteable types, but a couple
> of corrections:
> 
> - The type of an anonymous class instance creation expression, diamond or not,
> is always a non-denoteable class type. There's an anomaly in which *type
> inference* can't use that type and uses the superclass/interface instead, but
> that doesn't change the ultimate type of the expression.

Ok, got it, only type inference uses the supertype.

> 
> - The likely treatment of all anonymous instance creation expressions that are
> 'var' initializers, diamond or not, is one of 1) use the non-denoteable
> anonymous class type, or 2) use the class's immediate
> superclass/superinterface.

I agree.

Having a var that uses a non denotable type seems wrong to me, showing/hiding the type of a var should be a valid refactoring in any cases, IMO.
So i vote for (2).

> 
> —Dan

Rémi