A couple notes:
1) Eclipse chose to implement switch expression as a separate AST type from
switch statement. This provides explicit separation of different parsing and
other semantics. Also in Groovy 3, method references were implemented as a new
AST type instead of converting to MethodPointerExpression and lambda
expressions were implemented as a new AST type instead of converting to
ClosureExpression.
2) You mentioned mixed use of arrow and colon for cases (excerpt below). Are
you sure we want to support the mixing of case semantics? It may seem to offer
flexibility but may also confuse compiler as to whether a switch expression or
statement is to be generated.
def r = switch (a) {
case 6, 8 : {
// in Java, error occurs as no `yield` found.
// But in Groovy, you can think it as an optional `yield`, which is a
bit similar to optional 'return' in methods
'x'
}
case 9 -> 'y' // `case ... :`(colon) and `case ... ->`(arrow) can be
mixed as you need
}
Now that you have a prototype in hand for conversion to ClosureExpression with
nested SwitchStatement, would it be a good idea to at least try the
SwitchExpression route to see how much effort difference is involved?
