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 ]
