Hi Christopher,
@talk about final and inference: When you e.g.define a
variable/field/property in Groovy using final x = new Foo(), its type
will be Object, not Foo.
That matters e.g. when using reflection to discover specific class
members, as we do e.g. in the parts of our Groovy framework which
represent relational database tables columns as fields in Groovy classes.
To add to my initial arguments, when introducing variable definition
using val into Groovy, we would have:
1. def x = new Foo() // x is type Object, can be reassigned
2. var x = new Foo() // x is type Object, can (to my knowledge) be
reassigned any type (contrary to Java)
3. final x = new Foo() // x is type Object, cannot be reassigned
4. val x = new Foo() // x is type Foo, cannot be reassigned
I don't know, but to me that looks like a mess, and it gets worse since
afair behavior is slightly different under @CompileStatic...
Cheers,
mg
Am 13.04.2026 um 02:59 schrieb Christopher Smith:
I am a little late to the discussion, but I intended to make exactly
the same points as MG: duplicative, not clearly distinct, and overall
extra surface area with the only benefit perhaps "being like" some
other language that isn't Java. FWIW, I'm slightly confused by the
talk about final and inference; I've been using `final myVar` for as
long as I can remember with the expected semantics.
Christopher Smith
On Sun, Apr 12, 2026, 19:23 Caleb <[email protected]> wrote:
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.
