Re: GEP-16: val keyword for final declarations

Hi Caleb,

my main argument is that one does not need "val", if already existing 
"final" would do the same thing, i.e. do RHS type inference  (see also 
"To add to my initial arguments" in my reply to Christopher Smith).

Cheers,
mg

PS: To comment on some of your points:

 1. One does not always have the luxury of using an IDE when looking at
    Groovy code.
 2. A simple syntax highlighting editor (if that is available) might
    struggle with separating "val" the keyword from "val" the
    variable/field name (one of the many reasons why I think "val" is
    such a bad choice).
 3. @any declaration that takes multiple words: True for most ppl, full
    agreement, but we can use existing single word "final" keyword (or,
    if necessary, introduce a better one than "val"), as in final x =
    new Foo().
 4. @value-based semantics never having been a thing in any JVM
    languages: It is in Groovy, see @Immutable* (which GEP-16 explicitly
    states of being a non-goal of introducing a "val" keyword).

*https://docs.groovy-lang.org/latest/html/gapi/groovy/transform/Immutable.html


Am 13.04.2026 um 02:23 schrieb Caleb:
> 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.
>>
>>
>