Re: GEP-16: val keyword for final declarations

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.
>
>