8
$\begingroup$

After upgrading to Java 21, I realized that the promised switch expression has several surprising properties. The most surprising part is the yield keyword which must be inserted if a block is used in a branch. Like in

int x = switch (y) {
   ...
   case 7 -> {
     assert ...;
     8; // this is not allowed; a yield must be added in front
   }
};

While digging for a reason, I found JEP 354 which apparently introduced the syntax. Now, the obscure part is, that the very last paragraph of that documents indicates that such a move would be a bad idea. Are there any insights, why this contradiction was ignored and the yield syntax was introduced? Are there any reasons that would prevent using either a break expr syntax or having expressions at the end of a block in that context as a result?

$\endgroup$
7
  • $\begingroup$ Maybe a second question: Are there any ambiguities preventing an IDE from just inserting the yield as a quick fix? Since return also doesn't seem to be allowed there are only obscure other alternatives. $\endgroup$
    – feldentm
    Commented Jul 27 at 13:03
  • $\begingroup$ break expr seems to conflict with ordinary labelled break statements, so if anything it's more surprising that it made it into JEP 325 than that it wasn't used in the end. $\endgroup$
    – Michael Homer
    Commented Jul 27 at 21:53
  • $\begingroup$ “the very last paragraph of that documents indicates that such a move would be a bad idea.” I don’t understand this sentence. What paragraph are you referring to? What do you mean by “such a move”? I looked at JEP 354, and I have no idea what you’re talking about. $\endgroup$
    – Alexis King
    Commented Jul 27 at 22:00
  • $\begingroup$ @AlexisKing "The greater the divergence between switch..."; it's actually what made me ask this question, because it literally took me 15min to figure what all the error messages meant. It feels as if they have taken a complex route that is also different to what most others did if I'm not mistaken. $\endgroup$
    – feldentm
    Commented Jul 28 at 6:17
  • $\begingroup$ @MichaelHomer wouldn't there be an easy fix by adding braces and extending the break label code to hint that a brace might be required if this really is ambiguous? $\endgroup$
    – feldentm
    Commented Jul 28 at 6:18

1 Answer 1

0
$\begingroup$

It's more consistent to require the yield keyword than for it to be auto-inserted into the final expression. Consider the need to differentiate between the following two cases:

//Version 1
default -> {
    if(cond) {
        z=0;
    }
    yield 15;
}

//Version 2
default -> {
    if(cond) {
        yield z=0;
    }
    yield 15;
}
$\endgroup$
4
  • 3
    $\begingroup$ Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. $\endgroup$ Commented Jul 29 at 23:17
  • $\begingroup$ Yes, but you could equally do it by exchanging yield with break and reuse the existing keyword. Modulo ambiguity with break label expressions. My somewhat perverted proposal would be to leave out the ';' because it must be at the end of a block anyway. $\endgroup$
    – feldentm
    Commented Jul 30 at 14:49
  • $\begingroup$ @feldentm: I'll note that the very bottom of the JEP contrasts switch statements (default fall-through) with switch expressions. I think being a bit explicit about this contrast is necessary when you're working with two very similar constructs being available in the same language, especially given the possibility of refactoring from one to the other. That said, I'm only addressing your proposal to elide the keyword at the end of the block. $\endgroup$
    – Brian
    Commented Jul 30 at 17:24
  • 4
    $\begingroup$ @CommunityCompiler Nah, this answer is clear. $\endgroup$
    – CPlus
    Commented Jul 30 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .