It’s not a keyword in Java 10, it’s just a reserved identifier. In other words,
“int var = 10;” is still legal.
I’m thinking we should remain as conservative as Java in those matters.
> On 8 Mar 2018, at 02.23, MG <mg...@arscreat.com> wrote:
> 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 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.
>> 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
>>  https://issues.apache.org/jira/browse/GROOVY-8498
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html