Re: GEP-16: val keyword for final declarations

"var val" is Java, "val val" is not.

Am 14.04.2026 um 08:31 schrieb Guillaume Laforge:
> We also have var although we had def.
> It's a convenience to have some more copy/pasting friendliness with 
> languages that adopted val.
>
> On Tue, Apr 14, 2026 at 12:30 AM MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]> wrote:
>
>     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.
>>>
>>>
>>
>
>
>
> -- 
> *Guillaume Laforge*
> Apache Groovy committer*
> *
> Developer Advocate @ Google Cloud <https://cloud.google.com/>
>
>   * Blog: glaforge.dev <http://glaforge.dev/>
>   * X: @glaforge <http://twitter.com/glaforge>
>   * Bluesky: @glaforge.dev <https://bsky.app/profile/glaforge.dev>
>   * Mastodon: @[email protected] <http://%[email protected]/>
>