----- Mail original ----- > De: "Dan Smith" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > 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 <[email protected]> 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
