I'm very aware of that (there's a link, too, at the bottom of the JIRA), but from a syntax point of view, they've managed to keep things orthogonal, as I see it. We should rush things, and be sure to match the grammar obviously, surely, but I don't see how one would really block the other.
In Groovy, we'd have the same ambiguity in the 'case'-labels as with commands now, but I'm sure we could work with that (upper-case implies type name). For the switch expression vs. switch statement ambiguity, I'm sure we could fix that, by choosing the statement form if there is ambiguity. -Jesper > On 1 Mar 2018, at 18.34, Cédric Champeau <[email protected]> wrote: > > You have to be aware that this java syntax prepares the way for pattern > matching. I think we need to wait and see before doing it. > > Le 1 mars 2018 17:45, "Paolo Di Tommaso" <[email protected] > <mailto:[email protected]>> a écrit : > I agree that groovy should continue to be compatible with java syntax as long > as possible. > > > Cheers, > Paolo > > > On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge <[email protected] > <mailto:[email protected]>> wrote: > 1) Very useful :-) > 2) I think we should continue the compatibility with Java, like we're doing > for Groovy 3, and add that syntax when it's finalized. > 3) It's too early to think about the implementation, let's wait till the > syntax is crystalized first! > > But yeah, I like the idea of supporting it. > (and we could potentially support it before the Java version containing it is > released) > > Guillaume > > > On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller <[email protected] > <mailto:[email protected]>> wrote: > Hi list > > Java 11 (or perhaps 12) might see a new functionality known as switch > expressions (https://bugs.openjdk.java.net/browse/JDK-8192963 > <https://bugs.openjdk.java.net/browse/JDK-8192963>). > > While the current Groovy implicit return functionality works with the switch > statement as-is, the switch expression is a more general construct, basically > it is to the conditional operator (a ? b : c) what the switch statement is to > if/then/else-if/else. An example: > > int numLetters = switch (day) { > case MONDAY, FRIDAY, SUNDAY -> 6; > case TUESDAY -> 7; > case THURSDAY, SATURDAY -> 8; > case WEDNESDAY -> 9; > }; > with > case LABEL -> expression; > essentially sugar for > case LABEL: break expression; > As I see it: It could add utility to the Groovy language, and adopting it > would keep up the the Java-compatibility gap, which I think is a valuable > gateway-drug to discovering the joys of Groovy. The "break <expression> > syntax isn't pretty, but the arrows look fine and incur no syntax > compatibility problem, as far as I can see. > > Now, this being Groovy, the cases should surely support the extended > "isCase"-support, as described so well here: > http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html > <http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html> > > So, three questions remain: > 1) Useful or not? > 2) This Java compatibility - is it still a thing? I remember a similar > proposal a little while back, but this would align better with Java. > 3) This could be implemented using existing AST's if we really want to, but > it would be clumsy. This AST transformer compatibility - is it still a thing? > > -Jesper > > > > > > > -- > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform > > Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/> > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts>
