groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: New syntax explosion
Date Thu, 05 Oct 2017 23:01:54 GMT
On 05.10.2017 21:23, Andres Almiray wrote:
> FYI the switch statement is likely to become an expression in 
> (18.3 or 18.9) thus Groovy will have to support it at some point.

To give here a bit more fuel see JEP 305 and

I take from this, that the syntax is most likely not going to be the 
statement as expression. And in my opinion that does not make sense, 
just because it can return something does not make it an proper 
expression right away. After all we have the return statement, and it 
does return something, but it is no expression and nobody here would 
think about making it one.

In those documents they are even giving up on something like this:

switch (someNumber) {
   case 1:
   case 2:
     return "some number";
     return "unexpected number";

no break anymore, case 1 and case 2 cannot match at the same time. And 
now you have to have blocks for more than one line:

return switch (someNumber) {
   case 1 || 2 -> "some number"
   default -> { return "unexpected number" }

And since this is derived from the lambda constructs, it is clear I have 
a lambda body on the right, thus a return will return from the lambda, 
not the method I am in and then something like just return "some number" 
could be even illegal.

And since this will mean "abusing" switch-case for very different 
semantics I donĀ“t really expect this to be the final form, if the cases 
should support more complex expressions and destructering patterns.

And now compare with the Groovy version:

return switch (someNumber) {
   case 1:
   case 2:
     return "some number"
     return "unexpected number"

or without the internal returns:

return switch (someNumber) {
   case 1:
   case 2:
     "some number"
     "unexpected number"

Frankly I am unsure what I really prefer.

If we really want to just implement what java has, we have to wait till 
they finalize the syntax. If we want to go beyond that, we have again to 
wait. or we get again similar but different versions of syntax and 
semantic for a large number of cases as we have now with Closure and 

And btw, we should probably mention Scala here. look at their 
match-case. I think 
gives here an interesting overview. I am not saying we should do what 
Scala did here, but compare what is on this page with the documents from 
Brian. And you will find many many parallels and also maybe where we 
will go to. Maybe not with Case-classes like in Scala, but if 
destructering comes, then there will be bigger changes...

Anyway I think I start to loop here, so I better stop ;)

bye Jochen

View raw message