[GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Jesper Steen Møller
Hi list

Java 11 (or perhaps 12) might see a new functionality known as switch expressions (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

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



Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Guillaume Laforge
Administrator
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 <[hidden email]> 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).

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Paolo Di Tommaso
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 <[hidden email]> 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 <[hidden email]> 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).

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

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


Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Cédric Champeau
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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).

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

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


MG
Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

MG
You mean http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html ?

On 01.03.2018 18:34, Cédric Champeau 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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).

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

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



Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Jesper Steen Møller
Hi MG

On 1 Mar 2018, at 20.56, MG <[hidden email]> wrote:


It's been split up into JEP 325 (switch expr) and http://openjdk.java.net/jeps/305 (pattern matching, relies on JEP 325). I'm pretty sure your link has intentional "stawman"-grammar, that's been refined into the proposal in JEP305.

-Jesper


Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Jesper Steen Møller
In reply to this post by Cédric Champeau
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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).

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

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



MG
Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

MG
In reply to this post by Paolo Di Tommaso
+1 on Java compatibility, otherwise not a big fan of switch statments, I have always found the syntax inelegant and the appliaction domain too limited.
But it looks like with pattern matching and without the need to use break it could finally become less of a Mauerblümchen-statement for me...


I use the similar

final result = eval {
    // local variables
    if(...) { return ... }
    else if(...) { return ... }
    ...
}

static def eval(Closure cls) { cls() }

programming pattern on a regular basis*

it is one of the many reasons why adding support for inlining code to Groovy would make a lot of sense to me. In this case where the closure argument to the static eval-method is definitely only used once, replacing the closure with an inlined block construct would be the superior solution here. This poses the general question how much one could achieve in Groovy in a generic/flexible manner, if constructs like inlined closures would be added to the language... ?

*Note: Introducing a small helper method instead of the eval-construct can of course be the better solution, if one does not have to pass too many parameters to said method, and if one is not hard pressed to find a meaningful name for it...



On 01.03.2018 17:44, Paolo Di Tommaso wrote:
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 <[hidden email]> 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 <[hidden email]> 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).

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

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



Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Jochen Theodorou
In reply to this post by Jesper Steen Møller
On 01.03.2018 16:39, Jesper Steen Møller wrote:
[...]

> |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;|

to make this straight.

> int result = switch (s) {
>     case "Foo":
>         break 1;
>     case "Bar":
>         break 2;
>     default:
>         System.out.println("Neither Foo nor Bar, hmmm...");
>         break 3;
> }

is the long form of

> int result = switch (s) {
>     case "Foo" ->  1;
>     case "Bar" ->  2;
>     default:
>         System.out.println("Neither Foo nor Bar, hmmm...");
>         break 3;
> }

The default here has no shorter version, because they are using a
statement and need to return something in the expression. I understood
the proposal, that both forms are valid and can be mixed.

There is a few things I dislike...and most of all it is the break
command here.

> int accumulator = 0
> LOOP: for (T element : someList) {
>   accumulator += switch (element.type) {
>     case PLUS_ONE -> +1;
>     case MINUS_ONE -> -1;
>     case ERROR:
>       break LOOP;
>     case default -> 0
>   }
> }

with the idea that element.type is an enum... But my problem is with
break LOOP. Is LOOP the label LOOP, or is it a constant/variable?

If they need the break only to break out of the switch, then why not
capitalize on lambdas?

> int accumulator = 0
> LOOP: for (T element : someList) {
>   accumulator += switch (element.type) {
>     case PLUS_ONE -> +1;
>     case MINUS_ONE -> -1;
>     case ERROR -> {break LOOP;}
>     case default -> 0
>   }
> }

This would be much more aligned with what Java has, then you would
naturally use return if you are required to use statements. Plus it
would align more with what is in JEP-305 with for example "case Integer
i -> i+1". I would not even support the column version for a switch
expression.

And then of course there is the basic problem: you have to have a single
expression. Not many people are actually like using switch-case, I do,
but rarely this is for me in the break expression style as described.
For me this whole construct makes no sense without JEP-305 and for that
JEP you do not need some of the variants described at all. Let us not
forget that the switch-object is limited to quasi constants such as
strings, enum values and integers. They do not have the isCase
construct, thus no variant to do an equals based check. Even with
JEP-305, this is not changed. In theory you could do something like this
in Java:

>   accumulator += switch-case (element.type,
>     new Case(PLUS_ONE, -> +1),
>     new Case(MINUS_ONE, -> -1),
>     new Case(-> 0));

Then switch-case can be a generic function, that checks the Case objects
for the supplied matched and on equality executed the provided lambda.
This variant would realize the break expression version and would not
support labels or return statements (only as part of the lambda). But it
would be possible to do, even extensible to do more than just that - and
allow lambdas for the matcher as well.

[...]> 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
>
> So, three questions remain:
> 1) Useful or not?

for me not, it is one of the constructs I would not use. And given the
sentiment against switch-case by many programmers, they would not either.

> 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.

IMHO there is still work in that bug report to align better with Java ;)
For Groovy yes... if they add it to Java, we add it to Groovy... but not
because it is good or useful, just for compatibility

> 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?

Sure it is a thing, but I doubt it can be implemented using the AST.
switch-case is a statement, and while we have expression-statements
(expressions as statements) we do not have statements as expressions.
And I think none of the constructs in the bug would even pass the
parser. Without parser, no AST.

Meaning to implement this, you have to change the grammar,then you have
to introduce a new expression type and extend the visitors to support
it. And finally you may be able to match it to the switch statement, but:

int f(n, m) {
   int res = switch (n) {
     case 0 -> m+1;
     default -> switch(m) {
       case 0 -> f(n-1,1)
       default -> f(n-1, f(n,m-1))
     }
   }
   return res;
}

This will not be easy, because you will need a temporary variable if you
want to simulate this with the statement form... And frankly not sure it
is worth it compared to a "real" implementation in the compiler, which
will not have to use it. Of course you would normally not use
switch-case for this, it is just an example for a complex expression
having a nested switch-case-expression.

In summary: I would wait for what the Java guys decide in the end.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Remi Forax
Hi Jochen,

----- Mail original -----
> De: "Jochen Theodorou" <[hidden email]>
> À: "dev" <[hidden email]>
> Envoyé: Vendredi 2 Mars 2018 00:57:16
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

> On 01.03.2018 16:39, Jesper Steen Møller wrote:
> [...]
>> |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;|
>
> to make this straight.
>
>> int result = switch (s) {
>>     case "Foo":
>>         break 1;
>>     case "Bar":
>>         break 2;
>>     default:
>>         System.out.println("Neither Foo nor Bar, hmmm...");
>>         break 3;
>> }
>
> is the long form of
>
>> int result = switch (s) {
>>     case "Foo" ->  1;
>>     case "Bar" ->  2;
>>     default:
>>         System.out.println("Neither Foo nor Bar, hmmm...");
>>         break 3;
>> }
>
> The default here has no shorter version, because they are using a
> statement and need to return something in the expression. I understood
> the proposal, that both forms are valid and can be mixed.
>
> There is a few things I dislike...and most of all it is the break
> command here.
>
>> int accumulator = 0
>> LOOP: for (T element : someList) {
>>   accumulator += switch (element.type) {
>>     case PLUS_ONE -> +1;
>>     case MINUS_ONE -> -1;
>>     case ERROR:
>>       break LOOP;
>>     case default -> 0
>>   }
>> }
>
> with the idea that element.type is an enum... But my problem is with
> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?

this will not compile, because you can not use return or break/continue inside an expression switch.

>
> If they need the break only to break out of the switch, then why not
> capitalize on lambdas ?

it was the first idea :)
but lambda can capture effectively final local variable, when a case in an expression switch acts more like a routine so you can access any variables with no restriction. So re-using the same syntax for two different semantics is not a good idea.

The idea is that the expression switch should be used when it's a simple switch and the C switch with all it's subtle behaviors if the control flow is more complex,
exactly like you use for(:) if it's a simple loop and for(;;) if it's a more complex one.  

[...]

>
> bye Jochen

cheers,
Rémi
12