Hi Kevin, 
i've already proposed to remove 'case' (using match instead of ??) 
see 
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-December/000211.html
 
and 
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-December/000232.html
 
but Brian did not like it :) 

Rémi 

> De: "Kevin Bourrillion" <kev...@google.com>
> À: "Brian Goetz" <brian.go...@oracle.com>
> Cc: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Envoyé: Vendredi 2 Mars 2018 17:40:05
> Objet: Re: Disallowing break label (and continue label) inside an expression
> switch

> I would very much favor constraining what can be done inside an expression
> switch as sharply as we can.
> In fact, if we were designing the language from scratch, all at the same time,
> but having already decided the behavior of the conditional operators ?: ...
> might we not logically design this as similarly as possible to that?
> // compare this two-way choice
> return status == ABC ? something() : somethingElse();

> // to this three-way choice
> return status ?? { ABC -> something(); DEF, XYZ -> somethingElse(); default ->
> somethingOther(); }

> (stand-in syntax only)

> You could ideally think of ?: as sugar for the latter. Might we possibly be
> better off thinking of it this way, and not even worrying about 
> multi-statement
> cases (you can always extract a method)? It seems like several of our woes
> disappear.

> Something to consider is whether we want a construct that 
> readability-conscious
> developers will use only as the object of a return statement or variable
> assignment (which is what I think we have, currently), or one that they might
> comfortably use in-line in other circumstances, like

> Result r = methodCall(
> param1,
> param2,
> status ?? {
> ABC -> something();
> DEF, XYZ -> somethingElse();
> default -> somethingOther();
> });

> I can see that usage at least being debatable, while I suspect we might frown 
> on
> it all spelled out with `switch` and `case`....?

> As a last point in its favor, `null` can be treated completely normally - if 
> you
> didn't list `null ->` or `ABC, null ->`, etc., then use the default.

> On Fri, Mar 2, 2018 at 8:12 AM, Brian Goetz < [ mailto:brian.go...@oracle.com 
> |
> brian.go...@oracle.com ] > wrote:

>> Thanks for bringing this up. I remember it being discussed once before, but I
>> don't think we acted on it.

>> I agree that expression switch is an expression, and it should either yield a
>> value or throw something; breaking out of the middle of an expression is not
>> something we have, nor does it seem necessary. (Though I'm sure clever folks
>> could come up with a good example where it would be convenient.)

>> A sensible extension of this is no "return" from a switch expression either:

>> int foo(int x) {
>> return switch (x) {
>> case 1 -> 2;
>> case 2 -> 4;
>> case 3 -> 8;
>> default: return Integer.MAX_VALUE;
>> }
>> }

>> Like conditionals, then, switch expressions would either yield a value 
>> (through
>> breaking) or throw. This seems consistent, but...what happens when we nest a
>> statement in a switch expression?

>> void foo(int x, int y, int z) {
>> TOP:
>> switch (z) {
>> case 1:
>> int i = switch (x) {
>> case 1 -> 2;
>> case 2:
>> switch (y) {
>> case 1: return;
>> default: break TOP;
>> }
>> }
>> }
>> }

>> Do we disallow the "break TOP" and return in the inner switch? IOW, does the
>> expression form a barrier through which control can only pass via break or
>> exceptions?

>> On 3/2/2018 9:30 AM, Remi Forax wrote:

>>> Hi all,
>>> as far as i remember, the current idea to differentiate between a break 
>>> label
>>> and a break value is to let the compiler figure this out,
>>> i wonder if it's not simpler to disallow break label (and continue label) 
>>> inside
>>> an expression switch.

>>> After all, an expression switch do not exist yet, so no backward 
>>> compatibility
>>> issue, it may make some refactoring impossible but had the great advantage 
>>> to
>>> do not allow a lot of puzzler codes like the one below.

>>> enum Result {
>>> ONE, MANY
>>> }

>>> Result result(String[] args) {
>>> ONE: for(String s: args) {
>>> return switch(s) {
>>> case "several":
>>> case "many":
>>> break MANY;
>>> case "one":
>>> break ONE;
>>> default:
>>> continue;
>>> };
>>> }
>>> throw ...;
>>> }

>>> Rémi

> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ 
> mailto:kev...@google.com |
> kev...@google.com ]

Reply via email to