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.
