Sorry I had no time lately to read the whole thread, so do please forgive me if this was already discussed.
Nevertheless the most important thing I can't see here now is the consideration of legacy codebase which well might use “val” for identifier at many places (e.g., my projects do, thousands of occurrences). Won't this kind of usage break if the new keyword is added? If so, the drawbacks would very greatly outweigh any possible benefit. All the best, OC > On 14. 4. 2026, at 23:49, MG <[email protected]> wrote: > > Hi Paul, > Is the plan then for "final" to be the same as "val" with regards to type > inference, because that would mean we can actually ignore "val", otherwise we > at least will be forced to use it in our framework ? > Same question for "var": Will it also use the same type inference as "val", > and no longer just be an alias for "def" ? > Cheers, > mg > > PS: We use Groovy only in our team, and all of our method return types are > explicit, we only use def in the extremely rare case a method returns a > anonymous class instance. > > > Am 14.04.2026 um 22:31 schrieb Paul King: >> It is not really about copy-n-paste of Kotlin code. It is about Groovy >> feeling like a comfortable language to use for folks from different >> backgrounds and teams that work in multiple languages. >> >> Usage of "var" and "val" is totally optional. >> >> Some teams might be Groovy to the core and have CodeNarc rules forbidding >> "var" and "val". That's okay. >> >> Other teams that also work a lot with Kotlin or Scala, might always use >> "var" and "val" and always explicitly type their method return types (no >> "def" anywhere). That's okay too. >> >> Cheers, Paul. >> >> On Wed, Apr 15, 2026 at 5:38 AM MG <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi Gianluca, >>> >>> I agree: >>> I would say people copy & paste from Java, since there is so much code out >>> there and since Groovy (I think rightly so) has always tried very hard to >>> stay syntax compatible with it. >>> Kotlin is imho too different for one keyword to make much of a difference - >>> just think e.g. of its JavaScript-style postfix type syntax - and JetBrains >>> offers only Groovy-to-Kotlin autoconversion in IntelliJ, for obvious >>> reasons. >>> Scala uses the same type syntax, is less popular, as well as more >>> functional than Groovy, so there is even less argument to be made here to >>> have a small copy & paste compatibility. >>> Cheers, >>> mg >>> >>> >>> Am 14.04.2026 um 09:52 schrieb Gianluca Sartori: >>>> >>>> > It's a convenience to have some more copy/pasting friendliness with >>>> > languages that adopted val. >>>> >>>> Is this a real case? Do people copy paste from Java/Scala/Kotlin into a >>>> Groovy file/project? >>>> >>>> >>>> Also, raising the topic to a philosophical layer, sometimes adding >>>> features dilutes the concepts. >>>> I'd rather prefer to have a strong language with few concepts and its own >>>> identity. >>>> >>>> When we want to please anyone, we end up pleasing no one. >>>> >>>> I also believe we should start thinking about a Groovy version in the >>>> future (like version 10 for instance) where we make breaking changes to >>>> consolidate the language (like Python has done in version 3). >>>> Breaking changes are painful, risky and always too much work, but as with >>>> any other software the issue is "when" not "if". >>>> >>>> Mantra of the day: >>>> >>>> To add is simple, >>>> to remove is complicated. >>>> >>>> Sorry if this sounds a bit critical, my intention is to be helpful. >>>> >>>> Gianluca Sartori >>>> -- >>>> https://dueuno.com <https://dueuno.com/> >>>> >>>> On Tue, 14 Apr 2026 at 08:32, Guillaume Laforge <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> 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 <[email protected] >>>>> <mailto:[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: >>>>>> One does not always have the luxury of using an IDE when looking at >>>>>> Groovy code. >>>>>> 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). >>>>>> @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(). >>>>>> @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 <[email protected] >>>>>>> <mailto:[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 :-) ): >>>>>>>> "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). >>>>>>>> "val" looks a lot like "var". >>>>>>>> So if looking over code it is harder to spot an error in this regard >>>>>>>> And it might be confusing for ppl new to Groovy (unless they come from >>>>>>>> Kotlin or Scala, which I find unlikely to happen). >>>>>>>> "val" is a variable name ppl use (Contrary to final, def and var). >>>>>>>> While this would still work , e.g. "val val" just looks akward. >>>>>>>> As well as making code using "val" as a variable name generally worse >>>>>>>> to read. >>>>>>>> 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*. >>>>>>>> It seems to me this would not be a breaking change... (?) >>>>>>>> So while having type deduction would help our framework quite a bit, I >>>>>>>> would argue for: >>>>>>>> "final" to finally be type deducing* G-) >>>>>>>> Or at least for a different keyword to be used. >>>>>>>> It is late and I need to go to sleep, but from the top of my head: >>>>>>>> "fvar" or "fin" >>>>>>>> ("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]/> >
