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 <[email protected]=
e> 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 eccentric
> 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 abou=
t
> imports and more about avoiding/reducing redundant code duplication/over
> 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 be
> 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 in
> 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 early
> on and then it is mentioned as maybe being supported in the deliverables
> 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 on
> 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 about
> >>
> >>  something similar to Groovy's "it" in closures (maybe as an option, t=
o
> >>
> >>  also be able to break ambiguities without having to fall back to the
> >>
> >>  current fully qualified notation) ?
> >>
> >>  To me the floating-in-free-air-dot-prefix notation ( .RED ) looks lik=
e
> >>
> >>  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 Dart=
 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 compact
> >>
> >>  > syntax.]
> >>
> >>  >
> >>
> >>  > * GEP-29 is about supporting deeper null checking.
> >>
> >>  > [This is really about whether we want to fully support JSpecify whi=
ch
> >>
> >>  > seems to be gaining momentum. NullChecker in Groovy 6 already offer=
s
> >>
> >>  > partial support.]
> >>
> >>  >
> >>
> >>  > I don't really have the cycles to do major reviews of the GEPs yet,
> >>
> >>  > and I expect both will go through several iterations when we do. Fo=
r
> >>
> >>  > both we should ask ourselves whether we need the feature and weigh =
up
> >>
> >>  > each's value against the increased complexity. But I wanted to capt=
ure
> >>
> >>  > the ideas anyway, since I think they are worth thinking about in du=
e
> >>
> >>  > 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 featu=
res
> >>
> >>  > that will keep us busy for a while.
> >>
> >>  >
> >>
> >>  > But if other folks want to jump ahead and think about them, feel fr=
ee.
> >>
> >>  >
> >>
> >>  > Cheers, Paul.
> >>
> >>
>