The Oracle docs on var <https://docs.oracle.com/en/java/javase/17/language/local-variable-type-inference.html> are helpful, here. Specifically, this part:
var can be used for the following types of variables: - Local variable declarations with initializers: - Enhanced for-loop indexes: - Index variables declared in traditional for loops: - try-with-resources variable: - Formal parameter declarations of implicitly typed lambda expressions: A lambda expression whose formal parameters have inferred types is implicitly typed: - In JDK 11 and later, you can declare each formal parameter of an implicitly typed lambda expression with the var identifier: In short, `var` is purely a local variable placeholder in Java. Given that Java carefully limited var to work as a reserved type name, not a keyword to avoid interfering with existing code that used var as a variable name, I do think there's potential for semantic surprise with Java if Groovy expands it out to be a synonym for def. The Groovy semantics <https://groovy-lang.org/semantics.html> documentation that Gianluca refers to doesn't really advertise using var for fields or properties either, even if it does happen to work. Indeed, the warnings around how type inference works (or doesn't) for fields <https://groovy-lang.org/semantics.html#_variables_vs_fields_in_type_inference> makes me question whether we would want it to. Imagine the case of a Java developer seeing, "Oh, I can declare a field with var, assign its value immediately, and get type inference!" only for that to fail. I suspect that saying "def and var are basically just Object" probably isn't helpful in the documentation, and leads to this surprising case that Gianluca has run into here. This is a subjective case, and what surprises you depends a lot on your background, but my hunch on the "least surprising" thing to do for most people would be to document that "var is only for local variables, just like Java" and treat its validity for fields as an undocumented, possibly even a deprecated behavior. The note from the aforementioned doc is relevant: Why such a difference? The reason is *thread safety*. At compile time, we > can’t make *any* guarantee about the type of a field. Any thread can > access any field at any time and between the moment a field is assigned a > variable of some type in a method and the time is used the line after, > another thread may have changed the contents of the field. This is not the > case for local variables: we know if they "escape" or not, so we can make > sure that the type of a variable is constant (or not) over time. Note that > even if a field is final, the JVM makes no guarantee about it, so the type > checker doesn’t behave differently if a field is final or not. > > This is one of the reasons why we recommend to use *typed* fields. While > using def for local variables is perfectly fine thanks to type inference, > this is not the case for fields, which also belong to the public API of a > class, hence the type is important. > Groovy may be more liberal than Java, but it seems like we'd still want to steer people away from assuming "type inference works everywhere! I'm freeeeeeee!" Best, Jonny On Thu, Nov 21, 2024 at 12:27 PM most m <ubermenc...@gmail.com> wrote: > @Steve Etchelecu > > Java's var is a purely local type placeholder to elide the well-known > verbosity when declaring and initializing variables on the same line, e.g. > so that instead of writing "VeryLongTypename variable = new VeryLongType > name(...);", you could omit the variable's type declaration and leave it be > inferred from the initializer expression. > > I don't think javac considers it valid anywhere except a > declare-and-initialize statement and a foreach loop iterator declaration. > > On Thu, Nov 21, 2024, 20:17 Steve Etchelecu <steve.etchel...@gmail.com> > wrote: > >> I thought Gianluca made an excellent argument and helps modernize the >> language. Given Groovy’s symbiotic relationship with Java, it seems like >> the guidance here should probably be to follow Java’s usage as that likely >> keeps friction/confusion to a minimum. >> >> Not being a Java developer, it isn’t clear to me whether Java supports >> var as a return type though I assume it does for consistency. >> >> On Nov 21, 2024, at 11:10, Milles, Eric (TR Technology) via dev < >> dev@groovy.apache.org> wrote: >> >> >> I don't think semantically that "var name() { ... }" makes sense. >> >> One might argue that var for field and property do not make sense >> either. We could explore removing support for var on class members. >> ------------------------------ >> *From:* Gianluca Sartori <g.sart...@gmail.com> >> *Sent:* Thursday, November 21, 2024 10:57 AM >> *To:* dev@groovy.apache.org <dev@groovy.apache.org> >> *Subject:* [EXT] Re: Using `var` as method return type placeholder >> >> *External Email:* Use caution with links and attachments. >> Well, actually that's not true, Groovy supports creating fields and >> properties as well with `var`, so basically everything `def` does >> except return types. >> >> >> Gianluca Sartori >> -- >> Cell. +39 388 1026822 >> >> >> On Thu, 21 Nov 2024 at 17:41, Daniel Sun <sun...@apache.org> wrote: >> >> Hi Gianluca, >> >> `var` was introduced to Groovy just for the better compatibility of >> Java. Java just supports declaring variables with `var`, so does Groovy. >> >> Cheers, >> Daniel Sun >> >> On 2024/11/21 10:37:23 Gianluca Sartori wrote: >> > Hello everybody, >> > >> > My name is Gianluca Sartori, from Italy, I am the author of the open >> source >> > project Dueuno Elements ( >> https://github.com/dueuno-projects/dueuno-elements >> <https://urldefense.com/v3/__https://github.com/dueuno-projects/dueuno-elements__;!!GFN0sa3rsbfR8OLyAw!dKLiRGGSN06yuMZYXThMMGLu5ES8nh1240B7mX97feXlJsWHlparG8WQWaFKj2SCDpw5PVXgiTa1KWx0GZNXc3SM$> >> ) >> > and I am new to this list. >> > >> > I would like to start using the more Java-ish `var` instead of the >> > Python-ish `def` lexicon but I came across the fact that I cannot use >> `var` >> > as method return type placeholder. >> > >> > My understanding is that I can use `var` for both local variables and >> class >> > fields/properties but I cannot use it, for example, if I want to have a >> > read only property. The code below does not compile: >> > >> > class C { >> > var firstname >> > var lastname >> > >> > var getFullname() { >> > return firstname + ' ' + lastname >> > } >> > } >> > >> > var c = new C(firstname: 'Gianluca', lastname: 'Sartori') >> > c.fullname >> > >> > I'd like to switch to using `var` as a type placeholder, but having to >> use >> > `var` for variable declaration and keep using `def` for methods >> definition >> > is something I don't understand. I love Groovy because it is easy. This >> > restriction of the `var` type placeholder forces me to write code that >> > mixes Python lexicon the new Java lexicon. >> > >> > My main worry is with Grails controllers where we need to define an >> action >> > using `def` (or `Object`) as return type and define variables in the >> method >> > body. At the moment we have the following options: >> > >> > *def* index() { >> > *def* myVar = ... >> > } >> > >> > *def* index() { >> > *var* myVar = ... >> > } >> > >> > *def* index() { >> > *Object* myVar = ... >> > } >> > >> > *Object* index() { >> > *def* myVar = ... >> > } >> > >> > *Object* index() { >> > *var* myVar = ... >> > } >> > >> > *Object* index() { >> > *Object* myVar = ... >> > } >> > >> > I would like to write controllers like this: >> > >> > *var* index() { >> > *var* myVar = ... >> > } >> > >> > to keep the code clean and coherent with the Groovy documentation that >> > states clearly that *"If you think of def and var as an alias of Object, >> > you will understand in an instant."* >> > >> > Is this enough of an argument to ask for an implementation of `var` >> that is >> > fully intrechangable with `def`? >> > >> > Please let me know what is your opinion on that, >> > cheers, >> > Gianluca >> > >> > Gianluca Sartori >> > -- >> > Cell. +39 388 1026822 >> > >> >>
