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.
