We also have var although we had def. It's a convenience to have some more copy/pasting friendliness with languages that adopted val.
On Tue, Apr 14, 2026 at 12:30 AM MG <[email protected]> wrote: > Hi Caleb, > > my main argument is that one does not need "val", if already existing > "final" would do the same thing, i.e. do RHS type inference (see also "To > add to my initial arguments" in my reply to Christopher Smith). > > Cheers, > mg > > PS: To comment on some of your points: > > 1. One does not always have the luxury of using an IDE when looking at > Groovy code. > 2. A simple syntax highlighting editor (if that is available) might > struggle with separating "val" the keyword from "val" the variable/field > name (one of the many reasons why I think "val" is such a bad choice). > 3. @any declaration that takes multiple words: True for most ppl, full > agreement, but we can use existing single word "final" keyword (or, if > necessary, introduce a better one than "val"), as in final x = new Foo(). > 4. @value-based semantics never having been a thing in any JVM > languages: It is in Groovy, see @Immutable* (which GEP-16 explicitly states > of being a non-goal of introducing a "val" keyword). > > * > https://docs.groovy-lang.org/latest/html/gapi/groovy/transform/Immutable.html > > > Am 13.04.2026 um 02:23 schrieb Caleb: > > MG, > > A note on "val" looking similar to "var": any good IDE labels final and > non-final variables differently, e.g. IJ uses an underline. Even vim does > this afaik. The keywords look similar in isolation, sure, but everywhere > besides the declaration, you're not looking at the keyword for that info. > And with the underline on the variable, the declarations don't look similar > at all from experience. I've never been confused in Kotlin, even coming > from Java where var was the only similar keyword. > > Plus, from my experience, any declaration that takes multiple words to > communicate it (even something as small as "let mut") just feels clunky > compared to "val" and "var". It doesn't feel good to use, as it takes up > more space in your brain trying to read it. > > You're also intuitively dissuaded from using the more complicated one > because it takes an extra word, so if "final" is the extra word and it's > not necessary to basic operation, very few people will use it. (See: Java, > C, C++, literally every single language where "final" is the "second word".) > > On the topic of val meaning value-based semantics: that's never been a > thing in any JVM languages, and val isn't used as a keyword in the major > languages where it does exist. (Namely C, C++, and Rust.) > > Cheers, > Caleb > > On Sun, Apr 12, 2026, 6:35 PM MG <[email protected]> wrote: > >> Hi Paul, >> >> I still have the following gripes with using "val" (and two other >> languages having imho made a bad choice here still does not change that :-) >> ): >> >> 1. "val" for me indicates value- (as opposed to reference) based >> semantics, i.e. copy semantics / deep immutabilty, which the proposal >> explictly states is not the goal here (see Non-goals @Immutable in the >> GEP). >> 2. "val" looks a lot like "var". >> 1. So if looking over code it is harder to spot an error in this >> regard >> 2. And it might be confusing for ppl new to Groovy (unless they >> come from Kotlin or Scala, which I find unlikely to happen). >> 3. "val" is a variable name ppl use (Contrary to final, def and var). >> 1. While this would still work , e.g. "val val" just looks akward. >> 2. As well as making code using "val" as a variable name generally >> worse to read. >> 4. I see no need for "val", when it seems the same effect could be >> reached by changing the semantics of existing "final" to use RHS type >> deduction*. >> 1. It seems to me this would not be a breaking change... (?) >> 5. So while having type deduction would help our framework quite a >> bit, I would argue for: >> 1. "final" to finally be type deducing* G-) >> 2. Or at least for a different keyword to be used. >> 1. It is late and I need to go to sleep, but from the top of my >> head: "fvar" or "fin" >> 1. ("fin" would hit two birds with one stone: shorten the >> quite long "final" and supply type deduction). >> >> Cheers, >> mg >> >> *straightforward & stable, i.e. 99% what the user expects - make the >> frequent case easy/fast, make the rare case correct (i.e. require the >> developer to supply an explicit type). >> >> >> >> Am 12.04.2026 um 13:59 schrieb Paul King: >> >> Hi folks, >> >> We have been asked numerous times about the possibility of having a "val" >> keyword to match Kotlin and Scala. We also have had a related Jira open for >> more than 6 years. So I created a GEP to help frame a discussion about what >> would be involved and help us make a decision: >> >> https://groovy.apache.org/wiki/GEP-16.html >> >> I know we have "final", but many developers I speak to from the Kotlin >> and Scala worlds are big fans of "val" and believe it was the right name to >> use for those two languages. >> >> Given that it involves changes to only about 15 lines of production >> Groovy code and has well-identified impacts (arguably edge cases with >> workarounds), I am largely in favor of this proposal, but I am keen to hear >> other's thoughts. >> >> Cheers, Paul. >> >> >> >> > -- *Guillaume Laforge* Apache Groovy committer Developer Advocate @ Google Cloud <https://cloud.google.com/> - Blog: glaforge.dev - X: @glaforge <http://twitter.com/glaforge> - Bluesky: @glaforge.dev <https://bsky.app/profile/glaforge.dev> - Mastodon: @[email protected] <http://%[email protected]/>
