Hi folks,
Since Groovy 3, the Parrot parser reads a parenthesized bare name
followed by certain operators as a cast type rather than a value.
There are good reasons why we want exactly this in numerous cases, but
there are other cases where the expectation might be how they were
parsed in Groovy 2 or in Java.
For example, all of these fail with "unable to resolve class" today,
though all worked in Groovy 2:
def r = "A" + (b) + "C" // parsed as cast of (+ "C") to type b
def r = (answer) - 3
def r = (map.x) + 2
def r = (a) in [1, 2] // (a) in b also fails, but only in
// some statement contexts, not others
But there are gains from the Parrot approach that we wouldn't want to
back out of now. So, these all work today, and we would want them to
keep working unchanged:
(int) -1 // primitive casts are exempt from the
(long) -3 // proposed rule (distinct token type)
(Integer) -1 // cast of a negative literal
(Runnable) { ... } // SAM coercion
(Point) [3, 4] // list-to-constructor coercion
There's an assessment doc covering the ticket cluster (GROOVY-9864,
GROOVY-8913, GROOVY-10724, GROOVY-11320), the options considered and
declined, and a proposed fix targeting 6.0: restore the value reading
when the parenthesized name's final segment starts lowercase, plus a
better error message for the cases that stay cast-first, e.g.:
unable to resolve class ASDF; '(ASDF)' followed by an operand is
parsed as a cast - if 'ASDF' was meant as a value, wrap it in a
second set of parentheses, e.g. ((ASDF))
Implementation for review: https://github.com/apache/groovy/pull/2817
Ticket: https://issues.apache.org/jira/browse/GROOVY-10355
Assessment doc is attached as a PDF on the ticket.
Feedback welcome, particularly on the capitalization-based rule and on
what should happen to shapes like (a)[b] which have never worked in
any Groovy version. The ticket proposes a step forward but not all
cases.
Cheers, Paul.
