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

Hello,

I am not sure of the GEP process, however, I figured I could chime-in=20
with some, hopefully, helpful feedback.

I agree with the sentiment thus far: adding the dot shorthand is a=20
relatively easy improvement to the language ergonomics in some very=20
specific narrow cases. However, the syntax can/does seem a bit eccentric=20
or uncomfortable. Though, I can imagine myself getting used to it over=20
time as I am exposed to it more and more. There's a certain beauty in=20
the symmetry of it versus using a separate designator or signifier=20
instead (e.g. `:RED`).

That said, I thought I had read through the document fairly well and=20
understood what it was getting at. However, that said, I am not=20
intimately familiar with the other languages mentioned in the GEP (i.e.=20
Dart and Swift primarily) such that I have a firm grasp of/on the=20
semantics being proposed. Therefore, I wanted to perhaps re-state the=20
GEP with my understanding of the GEP as a way to clarify and perhaps=20
provide some feedback.

=E2=80=94

One of the fundamental benefits of this feature would be avoiding the=20
need to import enum/enum-like types (static or otherwise) if/when they=20
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=20
possible because of the method signature allowing the compiler to know=20
about and clearly infer the type being used and thus allows the user to=20
avoid importing the type explicitly and qualifying the usage of the=20
value with the aforementioned type.

Similarly the feature only works in contexts where the type is obvious=20
and clear to the compiler (e.g. explicit declaration in/on LHS=20
expressions): `Color my_color =3D .RED`. The benefit here being less about=
=20
imports and more about avoiding/reducing redundant code duplication/over=20
specification. Coupled with compile time type-safe literals over the=20
string coercion evaluation at runtime.

Assuming this understanding is correct, this makes sense and I can see=20
the value in each case. Albeit I am less inclined to see a _lot_ of=20
value in the second, but meh neither here or there around being more=20
expressive/less verbose being an a bad thing in and of itself (i.e. I=20
would rather have the option to be less verbose than always forced to be=20
verbose).

=E2=80=94

Any who, I wasn't _super_ clear on all of this in the examples/cases of=20
the GEP, so it might be worth elaborating and expanding a bit more.=20
Since in my first readings, I wasn't convinced and questioned how this=20
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=20
feature with the static factory methods (e.g. `.of(...)`, etc.). That=20
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=20
all cases, based on reading the GEP. I am uncertain if it would work=20
in/with the `=3D=3D` operator. For example, would it work for `if=20
(this.my_color =3D=3D .RED) { ... }` cases or not? Would it depend if=20
`my_color` was defined as something like `public Color my_color` or=20
`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=
`=20
example/case is mentioned a few times as being partially supported early=20
on and then it is mentioned as maybe being supported in the deliverables=20
section but then says its an excluded feature? So that's why I am=20
unsure.

Finally, more of a meta note/question, was this GEP written by AI or=20
assisted with AI? There seem to quite a few places that read as if it=20
were written by AI. I am not sure what the official policy or line is on=20
the whole usage of AI is in Groovy / GEP's, but if AI is involved in=20
anyway: it would be good etiquette to explicitly, clearly, and boldly=20
mention that the GEP was AI written and/or its contents' creation was=20
assisted with AI tools. This way more appropriate and applicable=20
scrutiny may be applied, especially for contradictions, inaccuracies,=20
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, to
>>
>>  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 like
>>
>>  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 a=
nd 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 which
>>
>>  > seems to be gaining momentum. NullChecker in Groovy 6 already offers
>>
>>  > 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. For
>>
>>  > both we should ask ourselves whether we need the feature and weigh up
>>
>>  > each's value against the increased complexity. But I wanted to captur=
e
>>
>>  > 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 feature=
s
>>
>>  > that will keep us busy for a while.
>>
>>  >
>>
>>  > But if other folks want to jump ahead and think about them, feel free=
.
>>
>>  >
>>
>>  > Cheers, Paul.
>>
>>