Spec draft for JEP 286 Local Variable Type Inference
daniel.smith at oracle.com
Thu Mar 30 16:53:30 UTC 2017
> 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."
> 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.
> 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.
- 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.
More information about the amber-spec-experts