[ 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)