GEP-28

Groovy already has three mechanisms for referencing enum constants without a static import, and after the @TypeChecked switch-case fix (GROOVY-12190, a GROOVY-11614 follow-up regression, fixed for Groovy 5.0.x/6.0) the current landscape is:

(The Java column is stable across JDK 17–25; Java’s only unqualified context is the switch case label, though since Java 21 the qualified form is also permitted there — JLS §14.11.1.)

Each existing mechanism has a structural limit:

A dot shorthand is resolved from the expected type of the position, not from the switch subject or the assignment target specifically, so one mechanism covers every position that has an expected type:

What remains genuinely unclosable, and is explicitly out of scope: positions where no context type exists even syntactically — dynamic-mode arguments to a dynamically dispatched call, and == where neither operand has a declared type.

The shorthand pays off in two different ways, and they are worth separating because they appeal to different readers.

No import at all. In an argument position the type name never appears in the calling file, so neither an import of the type nor a static import of its constants is needed:

This works because the parameter’s type is a resolved reference in logPrint’s signature; the caller’s import list plays no part in resolving `.INFO, exactly as it plays no part in def x = foo() where foo’s return type is unimported. This makes the shorthand strictly stronger than a static import, which still requires naming the type once (or importing `.* and polluting the file namespace).

A checked literal. In a declaration position the type name is still present, one token away, so the saving is small — and if brevity were the whole argument this position would be weak. It is not the whole argument. The realistic competitor to Color c = .RED is not Color c = Color.RED but the coercion Groovy programmers actually write today:

So the declaration case is about turning a value-blind string into a checked literal; the reduction in ceremony is a side benefit, not the point.

Languages have been converging on exactly this feature:

Java has no equivalent and none proposed; this is a place where Groovy would extend Java ergonomics rather than catch up, consistent with the language’s history.

The same sentence explains the exclusions, which is the real test of whether a mental model is honest rather than decorative. Each excluded position fails it identically — nothing was ever told to the compiler, so there is nothing to elide (the full position-by-position breakdown is in Context types):

Note that these are not "dynamic mode is unsupported". Dynamic mode supports the shorthand wherever a type was declared; it fails only where none was.

A dot shorthand is a leading . immediately followed by an identifier, in expression position:

It is valid only where a context type is available (below); anywhere else it is a compile-time error ("no context type for dot shorthand").

The table below is organised by what supplies the context type, not by compilation mode. That is the distinction that actually matters: a declared type is available to the compiler in every mode, so the first column is not "dynamic mode" but "works everywhere". Only the second column depends on static type checking. This list is the design surface for review; the intent is to match the positions where Groovy already applies target typing for SAM coercion or String-to-enum coercion, plus case labels and annotation attributes:

The only ❌ in the table is the position where nothing was declared and nothing can be inferred, which is the mental model doing its job rather than an arbitrary restriction.

Stage 1 alone closes every gap in the motivation table.

Stage 3 is the stage that draws the most enthusiasm in early feedback, and it is genuinely the nicest sugar of the three — but it carries a design cost the constant cases do not. In a declaration position (Duration d = .ofSeconds(3)) it is straightforward, since the context type is fixed before the call is resolved. In an argument position it is circular: the shorthand’s context type comes from the candidate parameter type, while candidate selection wants the argument’s type. Dart resolves this and provides a reference implementation to follow, but it is a substantially larger item than looking up a constant on a known enum, which is why it is staged last. Splitting Stage 3 so that declaration-position factories can land earlier than argument-position ones is an open question for review.

A dot shorthand is compile-time rewritten to the equivalent qualified reference (propX(classX(contextType), name) — the same rewrite GROOVY-8444’s case-label support performs today in VariableExpressionTransformer and, since the GROOVY-12190 regression fix, StaticTypesTransformation). Consequences:

Groovy attaches a line starting with . to the previous expression:

Proposed rule: chain continuation wins. A leading .name on a new line following a complete expression remains member access on that expression, exactly as today; a dot shorthand is only recognised where the grammar is inside an unfinished expression position (after =, (, ,, [, →, case, ==, return, an annotation member, etc.). This makes the feature whitespace-sensitive in one narrow way — Color c = followed by .RED on the next line is a shorthand because the = leaves the expression unfinished — and parser error messages for the genuinely ambiguous shapes must be written deliberately. This is the same resolution Swift uses.

println .5 is 0.5 today and must stay so. The lexer already distinguishes on the character following the dot; .DIGIT remains a numeric literal, .IDENT becomes a shorthand candidate. Mechanical, but the interaction with command expressions needs a decision: println .RED would become grammatically plausible while (dynamic println(Object)) never has a context type. Proposal: dot shorthands are not recognised in command-expression argument position (parenthesised calls only), keeping the command-syntax grammar untouched.

?., *., .&, ../..< ranges, and slashy strings do not collide with a leading-dot identifier in expression position, but each needs a grammar test; [.RED] vs the (invalid today) [..RED] range shapes should produce clear errors. Chaining off a shorthand (.RED.next()) parses naturally once .RED reduces to an expression; whether Stage 1 allows it or defers it is an open question (Swift allows chains whose final type re-enters the context type; Dart restricts more tightly).

Strictly additive. Every proposed form is a syntax error in Groovy 5/6, so no existing program changes meaning or compilation result. The continuation-line rule is defined so that all currently-valid leading-dot chains parse exactly as today. No runtime library surface is added; the rewrite emits ordinary qualified references.

None affected — the feature is purely a compile-time rewrite; no new classes, markers, or call-site shapes.

The grammar change is the visible surface: IntelliJ IDEA (its own Groovy parser) and Eclipse need parser support before the feature is usable in IDEs, and groovy-console/groovysh highlighting follows the shipped grammar. This is the same adoption path every grammar addition (e.g. switch expressions, ?[]) has taken, but it should be flagged to JetBrains early. Stub generation and Groovydoc are unaffected (rewrite happens before those consume the AST — to be verified for joint compilation in Phase 1).

The Groovy documentation’s enum section should present the full ladder in one place: qualified reference → static import → switch-case bare constants → dot shorthands → string coercion (dynamic values only), with the mode/position matrix from this GEP’s motivation section. The one-line rule from Mental model should lead that section: readers who take away only "the leading dot means the type this position already declares" can predict every supported position and every excluded one without consulting the matrix.