Spec draft for JEP 286 Local Variable Type Inference
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Mar 31 16:25:06 UTC 2017
----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: forax at univ-mlv.fr, "Dan Smith" <daniel.smith at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 30 Mars 2017 21:00:09
> Objet: Re: Spec draft for JEP 286 Local Variable Type Inference
> We're not voting yet -- we haven't even explained the issues yet :)
> The issue of non-denotable types is where all the complexity (and
> opportunity to get it wrong) in this feature lives. Dan will soon post
> some examples that hopefully will illustrate why both "just don't infer
> them, make the user say what they mean" and "just infer them, they're
> types" -- as "simple" and consistent as both of these seem -- are both
> extreme (and/or naive) positions.
There is a 3rd case, the inference give you a non-denotable types but you can lower it down to a compatible denotable type.
In that case,
- something will be inferred
- it's denotable so you can substitute var by the inferred type and it will work.
Examples of non-denotable type that can be lowered (i'm not saying we should use this rule, those are just examples)
- anonymous class -> super type
- intersection type -> first type (different from Object)
- null -> Object
- capture -> use the bound Luke
> (FWIW, initially I was in the "just don't infer" camp too; the
> attraction of that is that every program with `var` corresponds to an
> equivalent program with `var`. But the number of times where inference
> produces a capture or intersection is surprisingly high, and it will
> absolutely be perceived as "that stupid Java compiler, can't they just
> tell that..." Additionally, users will perceive the "penalty" of
> inference failure as messing up how their code prettily lines up -- and
> likely will seek to distort their code to avoid this aesthetic fail.)
I agree, but you do not have to infer a non-denotable type and stick with it.
> On 3/30/2017 2:24 PM, forax at univ-mlv.fr wrote:
>> 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).
More information about the amber-spec-experts