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
etc.

> 
> (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.

regards,
Rémi

> 
> 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 mailing list