You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "mgroovy (JIRA)" <ji...@apache.org> on 2018/05/17 23:03:00 UTC
[jira] [Commented] (GROOVY-8580) CLONE - Support `var` keyword of
Java10 (finalise behavior of keyword under @CompileStatic)
[ https://issues.apache.org/jira/browse/GROOVY-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479850#comment-16479850 ]
mgroovy commented on GROOVY-8580:
---------------------------------
@[~daniel_sun]: Could you explain the difference between variant 2 and 3 in more detail ? "Would only be allowed to change to sub-types of the initially inferred type": Changed where ?
> CLONE - Support `var` keyword of Java10 (finalise behavior of keyword under @CompileStatic)
> -------------------------------------------------------------------------------------------
>
> Key: GROOVY-8580
> URL: https://issues.apache.org/jira/browse/GROOVY-8580
> Project: Groovy
> Issue Type: New Feature
> Reporter: Daniel Sun
> Priority: Blocker
> Fix For: 3.x
>
>
> As part of GROOVY-8498 there is now support for the {{var}} keyword to provide compatibility with:
> http://openjdk.java.net/jeps/286 (Java 10)
> http://openjdk.java.net/jeps/323 (targeted for Java 11)
> For dynamic Groovy, {{var}} is an alias for {{def}}. Under {{@CompileStatic}}, there are three fairly obvious potential behaviors that could make sense for Groovy:
> * a direct alias for {{def}} in which case normal Groovy flow typing would apply (this is currently what is implemented but is more flexible than what Java developers might expect)
> * similar to the alias for {{def}} in that it allows the inferred type to change as further instructions are executed but it would only be allowed to change to sub-types of the initially inferred type (needs further investigation but if possible would combine some of the nice aspects of Groovy def and Java var behavior)
> * a direct equivalent of Java (this would be the most work and would differ greatly from Groovy behavior and in general would be hard to marry up with Groovy semantics)
> We need to finalize the behavior we want before releasing non-alpha versions of Groovy 3.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)