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