Re: Some draft GEPs: GEP-28 and GEP-29

Hey Paul,

Thanks for the great reply! Totally understand on being busy with all of=20
the releases.

First, regarding the notes on the GEP:

Thank you for the details, it really helped. As well, I appreciate the=20
clarifications and corrections (and mental model section). The updated=20
GEP looks much better and reads clearer and is easier to understand=20
(even though I am now biased since I've read it multiple times and no=20
longer have first-time reader objectivity).

Pedantic editing note, in the for "The two distinct benefits" section,=20
some of the code fences with backticks seem to be incorrect or something=20
is not escaped somewhere, leading to wonky rendering.

=E2=80=94

I do have some _curiosities_ regarding the "Method/constructor call=20
argument" part of the "Context types" section, as it relates to the "all=20
modes" category. I am assuming, given everything up until now in the=20
GEP, that this is _not_ quite what I think it is/what it is saying at=20
face value (i.e. "Dot shorthand doesn't work with method/constructor=20
calls"). There's a bit of nuance in there that I _think_ I understand =
=E2=80=A6=20
maybe.

My operating assumption is that, taking our `logPrint` example as=20
context: it's not saying that `logPrint("Hello World", .INFO)` does NOT=20
implicitly work/is NOT supported per se. Rather, it's more about the=20
method's signature at compile time. The nuance being the question of:=20
"For any given method X, does the method's signature specify the types,=20
at compile-time, or is it dynamic (i.e. using `def` for types)?=E2=80=9D?

Furthermore, I would take this to mean that even a single dynamic type=20
in a method's signature would "break" this from being possible, not just=20
the type of the parameter of the enum target (e.g. `public void=20
logPrint(def message, LogLevel level)` breaks this GEP's contract even=20
if/when used as `logPrint("Hello World", .RED)` since at compile-time=20
the types are not definitively known/dynamic dispatch is involved)? I=20
feel like my understanding here is very fuzzy and wrong.

I think that my understanding is leading me to believe that this is=20
overall alluding to the fact that `logPrint(String message, def=20
level)`/`public Logger(def level)` doesn't work/would not be compatible.=20
However, `logPrint(String message, LogLevel level)`/`public=20
Logger(LogLevel level)` _would_ work/be compatible because the types=20
(all of them) are/would be known at compile time, even without=20
`@CompileStatic` or `@TypeChecked`. Correct?

Apologies if I am being overly pedantic here.

=E2=80=94

 >>  > Similarly the feature only works in contexts where the type is=20
obvious
 >>  > and clear to the compiler (e.g. explicit declaration in/on LHS
 >>  > expressions): `Color my_color =3D .RED`. The benefit here being less=
=20
about
 >>  > imports and more about avoiding/reducing redundant code=20
duplication/over
 >>  > specification. Coupled with compile time type-safe literals over=20
the
 >>  > string coercion evaluation at runtime.
 >>  >
 >>  > Assuming this understanding is correct, this makes sense and I can=
=20
see
 >>  > the value in each case. Albeit I am less inclined to see a _lot_=20
of
 >>  > value in the second, but meh neither here or there around being=20
more
 >>  > expressive/less verbose being an a bad thing in and of itself=20
(i.e. I
 >>  > would rather have the option to be less verbose than always forced=
=20
to be
 >>  > verbose).
 >
 > Sure, but Groovy coerces String values to enum values too, so it isn=
=E2=80=99t
 > just about
 > a better score in code golf, but actual errors that would occur at=20
runtime like:
 > Color myColor =3D =E2=80=98READ=E2=80=99
 > could be caught at compile time.

Yeah, I should have clarified that more in my original remark around=20
"compile time type-safe literals". As you note, the dot-shorthand would=20
enhance type safety and make code safer/clearer in intent as well as=20
enable the compiler to find mistypes early on. Always a win in my book.

I completely agree with the value it brings in cases such as `Color=20
color =3D .RED` over `Color color =3D 'RED'` (fun fact: I didn't even know=
=20
that Groovy allows this/could do the string coercion into enum's ...=20
nice, dangerous ... but nice).

I could see someone making the case that this capability alone is a=20
strong enough reason to recommend/consider this feature further since it=20
significantly improves enum/enum-like types making them pleasant enough=20
and actually ergonomic to use.

Heck, time-permitting, I am probably going to tinker with things to get=20
some grammar for it working, slap-dashed of course.

=E2=80=94

Since my earlier reply, I have been deeply looking into this GEP/idea to=20
really understand it, poke some holes in it, etc. Some of the gotchas,=20
edge cases, and/or questions that I have come across include:

1. How would multiple possible ambiguous overloads/handling work? For=20
example, `public void classifyReport(Color color)` and `public void=20
classifyReport(ProjectStatus status)` where `enum ProjectStatus { RED,=20
YELLOW, GREEN }`. I'd throw a compiler error and force the user to=20
disambiguate though perhaps there is a more elegant solution.
2. Would `.valueOf` be supported? It would be somewhat redundant since=20
doing `Color color =3D str` would be the same, more or less, as `Color=20
color =3D .valueOf(str)`, right?
3. Could we do `.new(...)`? Would this just always be implicitly=20
supported?
4. Is there interplay with null-safe access?

I really do think this is a great feature and idea to add to the=20
language. Hopefully that is clear. It would absolutely be tremendously=20
useful, especially in actually getting to me use enums/enum-like types=20
at all, at the very least. As it stands today where using enum/enum-like=20
types is concerned, for me at least, they are elusive and archaic to the=20
code I see and write, so much so, that I had written enums off as=20
obsolete and irrelevant to/for practical use. Consequently, leading me=20
to completely forget the concept even exists and thus haven't used them=20
in years in many codebases/languages. I am sure I am not alone in that=20
sentiment, unfortunately.

Overall, it seems very possible, practical, and pragmatic, at least from=20
a surface review. Of course, the devil's in the details as they say.

=E2=80=94

Second, regarding the AI meta note (responses inline):

 > On the generative tooling discussion. Yes there has been some AI
 > assistance on the GEP. We "more or less" follow the ASF guidelines[1].

Thanks for the clarification and details. Totally get where you are=20
coming from. That policy is a good starting point, but I do wonder if=20
it's not a bit dated by now, at this point (it has a timeline reference=20
of June 2023 ... ancient in AI-tech term timelines).

Any who, my question was at high level, just very broadly knowing if the=20
content and AI overlapped in anyway. I saw tell-tale signs and=20
incongruity in the content that was indicative of AI but then again, I=20
know that I'm not an expert so I thought perhaps that I should just have=20
taken it at face value at first.

 > "More or less" because there is a lot of debate at the moment:
 > * Does it apply to docs and code?
 > * Should we use "Generated-by" or "Assisted-by" to properly reflect
 > the guideline which indicates the committer takes responsibility for
 > the content.

Good questions, I don't really have strong thoughts or opinions on these=20
beyond: do we expect someone to be reading the material in question=20
ever? If so, proper source and/or attribution credits are probably going=20
to be helpful then.

 > * If the intended purpose is to potentially produce a =E2=80=9Cmachine
 > parsable Tooling-Provenance file", why is AI that different to which
 > compiler I used, what editor did I code in, what checkstyle rules did
 > I use, and so forth.

Not to belabor the point, it's a good callout. I think that your=20
examples of compilers, editors, linters, etc. are not quite an=20
apples-to-apples comparison. Those tools are all deterministic in nature=20
and reproducible (in-spirit), while AI is not and cannot ever really be=20
(at least not what we call AI now and for all intents and purposes). Not=20
that it determinism makes a tool inherently better or worse, just that=20
there is more of an incentive to need to know about that tradeoff.

=E2=80=94

For clarity's sake, don't get me wrong, I am not anti-AI or such. My=20
perspective is that if one wants to use AI, go for it. More power to the=20
person. I use AI constantly. It's a great tool, like any other tool.

As far as I see it, it's just respectful and good etiquette to denote,=20
disclose, and attribute AI usage (in whatever form and however is=20
applicable/appropriate) in a properly, clearly, and explicitly denoted=20
fashion so that readers clearly know. Just seeing a tag of "AI" such=20
that I could then know "Yar, there be AI afoot here=E2=80=9D.

For clarity, the reasons being that if I know something was involved=20
with AI, then I should both scrutinize a lot more and dismiss it=20
point-blank when there are signs of skipped steps/missing logic or=20
hallucinations.

Essentially, rather than try to operate along the lines of "Ok, XYZ=20
human wrote this, there's the implicit assumption that they are a sane,=20
rational, and logical person. They clearly they know better than me and=20
things that I don't. Let me try extra hard to reason through the topic=20
more thoroughly and with an intent to really try to understand it"; the=20
reader can operate with the knowledge that "Non-determinism is=20
non-determinism. Don't try to figure out if/how randomness begets logic.=20
Be on guard.=E2=80=9D.

However, that's all just my opinion and take on it.

P.S.

I am not personally calling anyone out either. I just figured there=20
might be a blanket policy or something along those lines. I figured the=20
GEP was AI influenced in one way or another but wasn't sure and thought=20
it could just as well be "reader error" on my part (usually the case).

 > TBH, knowing which tools/models were used has some benefit, but some
 > folks see all the commit messages as being little more than free
 > advertising to the LLM companies.

Yep. Good point. Just seeing "AI" as a tag or something like that is a=20
footnote/disclosure is all I ever usually look for. I totally get the=20
perspective of not doing product-placement/endorsement and dealing with=20
all of that. I am in agreement.

 > These comments aren't to indicate that we should take guidelines
 > lightly, just that we have some time while things settle down. Most
 > people seem quite good at telling when content was
 > AI-generated/assisted.
 >
 > I think the most important thing for us is knowing that heavy AI
 > assistance should lead to heavy human review. And we should apply a
 > risk-based approach. AI assist on docs/tests is less risky than prod
 > code, and prod code itself has different risk profiles, e.g. a simple
 > DGM method addition vs multithreading, some of our metaprogramming
 > code, some of our type checking and bytecode gen code.

Fair enough. I tend to lean on the "heavy review" by default side for=20
any AI generated content. I guess it's more about the day coming when we=20
_can't_ easily tell when content had AI involvement.

=E2=80=94

Thanks again for the reply and warm welcoming to mailing list/community.=20
I hope to actively contribute and be helpful in some way.

Thanks,
Matt


------ Original Message ------
From "Paul King" <[email protected]>
To dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]
Date 8/3/2026 11:40:16=E2=80=AFPM
Subject Re: Some draft GEPs: GEP-28 and GEP-29

>
>
>Hi Matt,
>
>
>
>Thanks for your thoughtful reply. Sorry for the delay - I've been busy
>
>working on releases.
>
>
>
>On the generative tooling discussion. Yes there has been some AI
>
>assistance on the GEP. We "more or less" follow the ASF guidelines[1].
>
>"More or less" because there is a lot of debate at the moment:
>
>* Does it apply to docs and code?
>
>* Should we use "Generated-by" or "Assisted-by" to properly reflect
>
>the guideline which indicates the committer takes responsibility for
>
>the content.
>
>* If the intended purpose is to potentially produce a "machine
>
>parsable Tooling-Provenance file", why is AI that different to which
>
>compiler I used, what editor did I code in, what checkstyle rules did
>
>I use, and so forth.
>
>TBH, knowing which tools/models were used has some benefit, but some
>
>folks see all the commit messages as being little more than free
>
>advertising to the LLM companies.
>
>
>
>These comments aren't to indicate that we should take guidelines
>
>lightly, just that we have some time while things settle down. Most
>
>people seem quite good at telling when content was
>
>AI-generated/assisted.
>
>
>
>I think the most important thing for us is knowing that heavy AI
>
>assistance should lead to heavy human review. And we should apply a
>
>risk-based approach. AI assist on docs/tests is less risky than prod
>
>code, and prod code itself has different risk profiles, e.g. a simple
>
>DGM method addition vs multithreading, some of our metaprogramming
>
>code, some of our type checking and bytecode gen code.
>
>
>
>On to your comments on the GEP itself, you have a pretty good
>
>understanding. You pointed out some unclear bits, so I created a new
>
>version which improves some of those points and added some inline
>
>clarifications below.
>
>
>
>You have the general idea. Java programmers have the mental model that
>
>"I already told the compiler the type of my enum in the switch clause,
>
>so why should I have to tell it again in the case label".
>
>
>
>The PR extends that mental model to other places where we have already
>
>told the compiler about the type (or where it could infer it), so we
>
>avoid repeating that information. The leading dot also caters to
>
>dynamic Groovy, which would otherwise interpret some of these cases as
>
>properties.
>
>
>
>Cheers, Paul.
>
>
>
>[1] https://www.apache.org/legal/generative-tooling.html
>
>
>
>On Thu, Jul 30, 2026 at 3:17=E2=80=AFAM Matt M <mattm.apachegroovy@proton.=
me> wrote:
>>
>>
>>
>>  Hello,
>>
>>
>>
>>  I am not sure of the GEP process, however, I figured I could chime-in
>>
>>  with some, hopefully, helpful feedback.
>>
>>
>>
>>  I agree with the sentiment thus far: adding the dot shorthand is a
>>
>>  relatively easy improvement to the language ergonomics in some very
>>
>>  specific narrow cases. However, the syntax can/does seem a bit eccentri=
c
>>
>>  or uncomfortable. Though, I can imagine myself getting used to it over
>>
>>  time as I am exposed to it more and more. There's a certain beauty in
>>
>>  the symmetry of it versus using a separate designator or signifier
>>
>>  instead (e.g. `:RED`).
>>
>>
>>
>>  That said, I thought I had read through the document fairly well and
>>
>>  understood what it was getting at. However, that said, I am not
>>
>>  intimately familiar with the other languages mentioned in the GEP (i.e.
>>
>>  Dart and Swift primarily) such that I have a firm grasp of/on the
>>
>>  semantics being proposed. Therefore, I wanted to perhaps re-state the
>>
>>  GEP with my understanding of the GEP as a way to clarify and perhaps
>>
>>  provide some feedback.
>>
>>
>>
>>  =E2=80=94
>>
>>
>>
>>  One of the fundamental benefits of this feature would be avoiding the
>>
>>  need to import enum/enum-like types (static or otherwise) if/when they
>>
>>  can be inferred from their localized usage. For example:
>>
>>
>>
>>  ```
>>
>>  LogLevel.groovy
>>
>>  public enum LogLevel { =E2=80=A6 }
>>
>>
>>
>>  Loggers.groovy
>>
>>  public void log_print(String message, LogLevel level) { =E2=80=A6 }
>>
>>
>>
>>  App.groovy
>>
>>  log_print("Hello world", .INFO);
>>
>>  ```
>>
>>
>>
>>  Such usage of the feature, in the context of the method call, is only
>>
>>  possible because of the method signature allowing the compiler to know
>>
>>  about and clearly infer the type being used and thus allows the user to
>>
>>  avoid importing the type explicitly and qualifying the usage of the
>>
>>  value with the aforementioned type.
>
>
>
>Spot on. I added a clarification in the GEP on this.
>
>
>>
>>  Similarly the feature only works in contexts where the type is obvious
>>
>>  and clear to the compiler (e.g. explicit declaration in/on LHS
>>
>>  expressions): `Color my_color =3D .RED`. The benefit here being less ab=
out
>>
>>  imports and more about avoiding/reducing redundant code duplication/ove=
r
>>
>>  specification. Coupled with compile time type-safe literals over the
>>
>>  string coercion evaluation at runtime.
>>
>>
>>
>>  Assuming this understanding is correct, this makes sense and I can see
>>
>>  the value in each case. Albeit I am less inclined to see a _lot_ of
>>
>>  value in the second, but meh neither here or there around being more
>>
>>  expressive/less verbose being an a bad thing in and of itself (i.e. I
>>
>>  would rather have the option to be less verbose than always forced to b=
e
>>
>>  verbose).
>
>
>
>Sure, but Groovy coerces String values to enum values too, so it isn't
>
>just about
>
>a better score in code golf, but actual errors that would occur at runtime=
 like:
>
>Color myColor =3D 'READ'
>
>could be caught at compile time.
>
>
>>
>>  =E2=80=94
>>
>>
>>
>>  Any who, I wasn't _super_ clear on all of this in the examples/cases of
>>
>>  the GEP, so it might be worth elaborating and expanding a bit more.
>>
>>  Since in my first readings, I wasn't convinced and questioned how this
>>
>>  avoids the required import anyways to even use the enum/enum-like type.
>>
>>
>>
>>  I do see a lot of value/"nice'ness" with/for being able to use this
>>
>>  feature with the static factory methods (e.g. `.of(...)`, etc.). That
>>
>>  would be really nice and just add that extra bit of nice syntax sugar.
>>
>>
>>
>>  I am still a bit hazy on how/where this shorthand would apply exactly i=
n
>>
>>  all cases, based on reading the GEP. I am uncertain if it would work
>>
>>  in/with the `=3D=3D` operator. For example, would it work for `if
>>
>>  (this.my_color =3D=3D .RED) { ... }` cases or not? Would it depend if
>>
>>  `my_color` was defined as something like `public Color my_color` or
>>
>>  `public def my_color`? Again, I am not _super_ clear on this.
>>
>>
>>
>>  The GEP seems to have a bit of contradictory notes around this. The `=
=3D=3D`
>>
>>  example/case is mentioned a few times as being partially supported earl=
y
>>
>>  on and then it is mentioned as maybe being supported in the deliverable=
s
>>
>>  section but then says its an excluded feature? So that's why I am
>>
>>  unsure.
>
>
>
>Yeah, that wasn't clear and I have improved it. Let me know if it
>
>still seems too complex.
>
>
>>
>>  Finally, more of a meta note/question, was this GEP written by AI or
>>
>>  assisted with AI? There seem to quite a few places that read as if it
>>
>>  were written by AI. I am not sure what the official policy or line is o=
n
>>
>>  the whole usage of AI is in Groovy / GEP's, but if AI is involved in
>>
>>  anyway: it would be good etiquette to explicitly, clearly, and boldly
>>
>>  mention that the GEP was AI written and/or its contents' creation was
>>
>>  assisted with AI tools. This way more appropriate and applicable
>>
>>  scrutiny may be applied, especially for contradictions, inaccuracies,
>>
>>  and/or hallucinations.
>>
>>
>>
>>  Any who, I hope this has been helpful. Looks really cool.
>>
>>
>>
>>  Thanks,
>>
>>  Matt
>>
>>
>>
>>
>>
>>  ------ Original Message ------
>>
>>  From "Paul King" <[email protected]>
>>
>>  To "Groovy_Developers" <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]>
>>
>>  Date 7/29/2026 12:06:10=E2=80=AFAM
>>
>>  Subject Re: Some draft GEPs: GEP-28 and GEP-29
>>
>>
>>
>>  >
>>
>>  >
>>
>>  >Yeah, it will be one of those subjective things.
>>
>>  >
>>
>>  >
>>
>>  >
>>
>>  >Some folks think it is ugly to have to type "Color.RED" when Java lets
>>
>>  >
>>
>>  >you just type "RED". We have that down to just one case now (or you
>>
>>  >
>>
>>  >can use an import) but for dynamic Groovy we probably can't do better.
>>
>>  >
>>
>>  >The GEP proposal would give another option. And for some folks all the
>>
>>  >
>>
>>  >extra places they can shorten using a consistent pattern might seem
>>
>>  >
>>
>>  >like a beautiful thing to them, but yes I still fall into the camp of
>>
>>  >
>>
>>  >"it looks a little awkward", but I am still keen to explore the
>>
>>  >
>>
>>  >possibilities.
>>
>>  >
>>
>>  >
>>
>>  >
>>
>>  >Cheers, Paul.
>>
>>  >
>>
>>  >
>>
>>  >
>>
>>  >On Wed, Jul 29, 2026 at 6:25=E2=80=AFAM MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]> wrote:
>>
>>  >>
>>
>>  >>
>>
>>  >>
>>
>>  >>  Just a quick feedback for GEP-28: I saw that "Sigil variants" (@RED=
,
>>
>>  >>
>>
>>  >>  :RED, etc) are already stated as rejected in the GEP, but what abou=
t
>>
>>  >>
>>
>>  >>  something similar to Groovy's "it" in closures (maybe as an option,=
 to
>>
>>  >>
>>
>>  >>  also be able to break ambiguities without having to fall back to th=
e
>>
>>  >>
>>
>>  >>  current fully qualified notation) ?
>>
>>  >>
>>
>>  >>  To me the floating-in-free-air-dot-prefix notation ( .RED ) looks l=
ike
>>
>>  >>
>>
>>  >>  an error / ugly...
>>
>>  >>
>>
>>  >>
>>
>>  >>
>>
>>  >>  Cheers,
>>
>>  >>
>>
>>  >>  mg
>>
>>  >>
>>
>>  >>
>>
>>  >>
>>
>>  >>  Am 28.07.2026 um 08:30 schrieb Paul King:
>>
>>  >>
>>
>>  >>  > Hi folks,
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > I created two more draft GEPs tentatively targeting Groovy 7:
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > * GEP-28 is about supporting DOT-notation that is supported by Da=
rt and Swift.
>>
>>  >>
>>
>>  >>  > [I like the brevity it gives but it also takes some getting used =
to
>>
>>  >>
>>
>>  >>  > and it complicates things if Java ever develops a different compa=
ct
>>
>>  >>
>>
>>  >>  > syntax.]
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > * GEP-29 is about supporting deeper null checking.
>>
>>  >>
>>
>>  >>  > [This is really about whether we want to fully support JSpecify w=
hich
>>
>>  >>
>>
>>  >>  > seems to be gaining momentum. NullChecker in Groovy 6 already off=
ers
>>
>>  >>
>>
>>  >>  > partial support.]
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > I don't really have the cycles to do major reviews of the GEPs ye=
t,
>>
>>  >>
>>
>>  >>  > and I expect both will go through several iterations when we do. =
For
>>
>>  >>
>>
>>  >>  > both we should ask ourselves whether we need the feature and weig=
h up
>>
>>  >>
>>
>>  >>  > each's value against the increased complexity. But I wanted to ca=
pture
>>
>>  >>
>>
>>  >>  > the ideas anyway, since I think they are worth thinking about in =
due
>>
>>  >>
>>
>>  >>  > course. We should be comfortable with rejecting GEPs if the ideas
>>
>>  >>
>>
>>  >>  > don't belong or belong somewhere else.
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > To be honest, we already have a backlog of potential Groovy 7 fea=
tures
>>
>>  >>
>>
>>  >>  > that will keep us busy for a while.
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > But if other folks want to jump ahead and think about them, feel =
free.
>>
>>  >>
>>
>>  >>  >
>>
>>  >>
>>
>>  >>  > Cheers, Paul.
>>
>>  >>
>>
>>  >>
>>
>>