<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">Note too that we also
        considered the case (heh) of a switch with _zero_ selectors, as
        a replacement for chains of if-else that all produce a value to
        be consumed in a uniform way:<br>
        <br>
            String s = switch { <br>
                case when e1 -> x;<br>
                case when e2 -> y;<br>
                default -> z;<br>
            }<br>
        <br>
        This obviously doesn't have the problems I outlined with
        multi-selector, but it is definitely "weirder".  It seeks to
        capitalize on the strength reduction of switch relative to an
        if-else chain, but I'm also not convinced this one carries its
        weight.<br>
        <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 9/27/2023 10:18 AM, Brian Goetz
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:e30726b3-c17f-af97-a4cb-3227a96c5344@oracle.com">
      
      <font size="4"><font face="monospace">[ dropping amber-dev ]<br>
          <br>
          Yes, we've discussed this before.  A switch could have
          multiple selector values:<br>
          <br>
              switch (a, b)<br>
          <br>
          and cases could be structured similarly:<br>
          <br>
              case (P, Q):<br>
          <br>
          All of this isn't hard.  The real question is, does it result
          in better or worse code?  My sense is that it look really
          pretty in the simple examples, but as the number of selectors
          and the size of the patterns increases, it is likely to become
          an unreadable soup.  So that's a concern.<br>
          <br>
          As an example of a "the simple cases are very pretty", I give
          you a world-class FizzBuzz:<br>
          <br>
              Function<Integer, String> fizzbuzz = <br>
                  x -> switch (x % 3, x % 5) { <br>
                           case (0, 0) -> "FizzBuzz";<br>
                           case (0, _) -> "Fizz";<br>
                           case (_, 0) -> "Buzz";<br>
                           default -> Integer.toString(x);<br>
                       };<br>
          <br>
          (I might have gotten my Fizz and Buzz backwards, I didn't
          bother to look it up.)  <br>
          <br>
          <sarcasm><br>
          I see the appeal in "Java is the #1 language for writing
          FizzBuzz", but I am not sure this is the stewardship rubric we
          are looking for :)<br>
        </font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"></sarcasm><br>
              <br>
            </font></font>Another problem (and this one is of our own
          making) is that comma already means something in cases.  So <br>
          <br>
              case 0, 1<br>
          <br>
          means something subtly different from<br>
          <br>
              case (0, 1)<br>
          <br>
          which is not particularly nice.  Yes, the type checker will
          disambiguate for you, but we are not used to both `X` and
          `(X)` being valid in the same context but meaning different
          things.  (Worse, when you combine these where you have
          multiple tuple patterns on one case, it's even more case
          soup.)  <br>
          <br>
          So I put this one in the category of "simple enough to specify
          and implement, has obvious motivating use cases, but not sure
          it actually improves the language."<br>
          <br>
          <br>
        </font></font><br>
      <div class="moz-cite-prefix">On 9/27/2023 10:03 AM, Remi Forax
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:525180955.6049957.1695823398327.JavaMail.zimbra@univ-eiffel.fr">
        <pre class="moz-quote-pre" wrap="">Hi recently Clément BOUDEREAU has reported a bug on amber-dev and unrelated to that bug,
taking a look to the code I've noticed this


       int compareTo(final Value<T> o) {
            return switch (new Tuple<>(this, o)) {
                case Tuple<Value<T>, Value<T>>(Value.Infinite<T> _, Value.Infinite<T> _) -> 0;
                case Tuple<Value<T>, Value<T>>(Value.Infinite<T> _, Value.Fixed<T> _) -> 1;
                case Tuple<Value<T>, Value<T>>(Value.Fixed<T> _, Value.Infinite<T> _) -> -1;
                case Tuple<Value<T>, Value<T>>(Value.Fixed<T> fst, Value.Fixed<T> snd) ->
                    fst.value.compareTo(snd.value);
            };
        }

Here what Clément want is to match two values (here, "this" and "o") but the only way to do that is to wrap them into a pair (here named Tuple),
Should we not provide a way to match several values natively ?

Something like

        int compareTo(final Value<T> o) {
            return switch (this, o) {
                case (Value.Infinite<T> _, Value.Infinite<T> _) -> 0;
                case (Value.Infinite<T> _, Value.Fixed<T> _) -> 1;
                case (Value.Fixed<T> _, Value.Infinite<T> _) -> -1;
                case (Value.Fixed<T> fst, Value.Fixed<T> snd) ->
                    fst.value.compareTo(snd.value);
            };
        }

regards,
Rémi
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>