Re: GEP-16: val keyword for final declarations

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 <mgbiz-yvYIh6MZAuFWk0Htik3J/[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.
>>
>>
>