On 05.10.2017 21:23, Andres Almiray wrote:
FYI the switch statement is likely to become an expression in Java.next
(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
http://cr.openjdk.java.net/%7Ebriangoetz/amber/
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";
break;
default:
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"
default:
return "unexpected number"
}
or without the internal returns:
return switch (someNumber) {
case 1:
case 2:
"some number"
break;
default:
"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
lambdas.
And btw, we should probably mention Scala here. look at their
match-case. I think
https://www.artima.com/pins1ed/case-classes-and-pattern-matching.html
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
