Hi Daniel,

I agree that it does not make much sense to closely mirror the details of the Java specifications in Groovy, but I still think that simply treating var the same as def looses some potential for the static compilation case, e.g.:
var myVar = new Foo()
myVar = 123 // Allowed when var === def, forbidden if myVar has type Foo

For different reasons (scenarios where reflection on classes is used, such as in my library), the same goes for
final myField = new Foo() // myField should have type Foo

As http://openjdk.java.net/jeps/286  correctly mentions, type inference is not magic, but in my mind this comes down to a 90+% solution again, namely that covering the two cases:
1) var myVar = new Foo()  // myVar  is of type Foo
2) var myVar = myMethod() // myVar is of return type of myMethod
will cover a lot of ground, and I therefore believe it would be ok to fall back to var/final === def in all other cases for now. If someone wants to / has time, he can improve on this later.

My 8.05762816 Cent,

On 08.03.2018 00:53, Daniel Sun wrote:
Hi all,

     As GROOVY-8498[1] describes as follows, in order to compatibility with
Java 10+, Groovy should support `var` the reserved type name. The reference
implementation has been pushed to master and 2.6.0 branch, you can find it
via the link[2].

    Any thoughts?

This is to provide compatibility with:
http://openjdk.java.net/jeps/286 (Java 10)
http://openjdk.java.net/jeps/323 (targeted for Java 11)

Java 10 provides var to allow reduced ceremony by avoiding manifest
declaration of types for local variables for cases where type inferencing
can be supported. Groovy already does this with "def" and has it's own
approach for type inferencing within type-checked/compile static code. With
this in mind, it seems to make most sense for Groovy to have "var" as an
alias for "def" rather than closely mimic only the use cases allowed by


[1] https://issues.apache.org/jira/browse/GROOVY-8498

Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Reply via email to