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.
—
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 { … }
Loggers.groovy
public void log_print(String message, LogLevel level) { … }
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.
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 = .RED`. The benefit here being less about
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).
—
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 `==` operator. For example, would it work for `if
(this.my_color == .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 `==`
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.
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" <[email protected]>
Date 7/29/2026 12:06:10 AM
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 AM MG <[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 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 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 capture
>>
>> > 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 features
>>
>> > that will keep us busy for a while.
>>
>> >
>>
>> > But if other folks want to jump ahead and think about them, feel free.
>>
>> >
>>
>> > Cheers, Paul.
>>
>>
