RFR: 8177466: Add compiler support for local variable type-inference

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Wed Sep 20 21:47:10 UTC 2017


On 9/19/17 17:38, Maurizio Cimadamore wrote:
> You touch on an important point - the type inferred for 'var' might be 
> non-denotable - when that happens, re-assignment is going to give 
> 'surprising' results, where the level of surprise might vary depending 
> on what the expectations for this feature are.
> 
> This issue was discussed here:
> 
> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-April/000023.html 

Thank you for the link, I have no any comments about the changes, it is 
fine to me(not a reviewer in compiler-dev), I tried to replace the usual 
types by the "var" inside the jdk and test this functionality and it 
seems to work w/o any issues except the cases I sent previously.

> 
> 
> As you can see, there's a multitude of options in the design space when 
> defining what 'var' means. The currently implemented approach (and spec 
> draft) chose this point:
> 
> * forbid 'null'
> * normalize captured types
> * leave intersection types and anonymous classes as is
> 
> (note that for the last two bullets - there might occur recursively 
> inside other types, such as arrays or parameterized types).
> 
> I would suggest that we try and keep this thread confined to the code 
> review - that said, your feedback is greatly appreciated, and I suggest 
> you to direct it to the amber-spec-experts mailing list.



-- 
Best regards, Sergey.


More information about the compiler-dev mailing list