<div dir="ltr"><div dir="ltr"><div>I haven't played with switch expressions, but I think of them kind of like this but much more performant...</div><div><br></div><div>int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6;</div><div><br></div><div>This statement assigns a value to y no matter what x is since the 6 is the "default" case.  The following wouldn't make any sense.  What gets assigned to y in the last case?<br></div><div><br></div><div>
int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? ;

</div><div><br></div><div>Note: I realize that switch statements are based on a table (e.g., enum) or hash table lookup (e.g., String).  This provides O(1) case selection; whereas, the above is O(n) where n is the number of == + 1.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 18, 2022 at 4:42 PM Hunor Szegi <<a href="mailto:hunor.szegi@gmail.com">hunor.szegi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">Hi All,</div><div style="font-size:small"><br></div><div style="font-size:small">I really like the progress of adding pattern matching to Java (and a lot of other features). I can not wait to use it in productive code (non-preview). But I would like to give you feedback about a tiny detail, about the totality of switch statements.</div><div style="font-size:small"><br></div><div style="font-size:small">Surely, the totality is necessary at switch expressions, but forcing it at a statement is questionable.</div><div style="font-size:small"><br></div><div style="font-size:small">It can be helpful for the programmers to check the totality in those cases when the intent is that. But it is quite common to create a switch statement that doesn't handle all of the possibilities. Why would it be different using patterns? Why is it beneficial to force totality? This check can be an IDE feature. (Or the programmer can try adding a default clause, and the duplicated totality will be shown as an error. But I know it isn't convenient.)</div><div style="font-size:small"><br></div><div style="font-size:small">Honestly I feel that the rule, when the totality is forced, is dictated simply by the necessity of backward compatibility. What will happen if a new type (for example double) will be allowed for the selector expression? The backward compatibility wouldn't be an issue, but it would be weird behaving differently with an int compared to a double, so I guess the totality won't be forced. What would happen if the finality requirement was removed, and the equality could be checked for all types? What about the totality check in this imagined future?</div><div style="font-size:small"><br></div><div style="font-size:small">Of course the best would be to allow the totality check somehow if the intent is that. A warning could be a solution, but that can be annoying. It will force the programmers to suppress it, or to add a default clause (what is the current solution). Adding a default clause could be treated as marking the intent: we don't want totality. But the actual syntax does not represent it clearly.<br></div><div style="font-size:small"><br></div><div style="font-size:small">Additionally, there are issues with the "empty" default clause. In the JEP the "default: break;" was recommended, but interestingly it doesn't work with the arrow syntax. ("default -> break;" is a compile time error, only the "default: {break;}" is possible.) We can use both the "default: {}" and "default -> {}", which is fine. But while the "default:" is possible (without body), the "default ->" is an error. I don't know what is the reason behind it. Allowing an empty body with the arrow syntax would make the actual solution a little bit cleaner.</div><div style="font-size:small"><br></div><div style="font-size:small">I think forcing the totality at statements is partly an intent for uniformity. The best would be if the same rules were applied to all cases, regardless if it is a statement or expression, old or arrow syntax. But backward compatibility can't allow full uniformity, it moves the separation into the middle of a box, instead of a clear distinction between a statement and expression. It creates more cases.</div><div style="font-size:small"><br></div><div style="font-size:small">It would be possible, forcing the totality only at the arrow syntax. But that would move some of the programmers using the old syntax, which may be less fortunate.</div><div style="font-size:small"><br></div><div style="font-size:small">It would be possible to allow the programmer to mark the intended totality. Maybe a new keyword would be too much for this purpose. Alternatively I can imagine allowing annotations at a switch statement/expression in the future. For example:</div><div style="font-size:small"><br></div><div style="font-size:small">@total</div><div style="font-size:small">switch (x) {</div><div style="font-size:small">...</div><div style="font-size:small">}</div><div style="font-size:small"><br></div><div style="font-size:small">If this syntax isn't possible, the annotation could be added right before the opening curly bracket. Alternatively a warning suppress annotation could be used specifically for the switch.</div><div style="font-size:small">But this is only a brainstorming. My main point is that I don't think the totality should be forced at switch statements. Or it should cause only a warning.</div><div style="font-size:small"><br></div><div style="font-size:small">I hope my feedback isn't pointless. <span style="color:rgb(0,0,0);white-space:pre-wrap">I'd be very interested to hear other people's opinions.</span></div><div style="font-size:small"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div style="font-size:small"><span style="color:rgb(0,0,0);white-space:pre-wrap">Thank you in advance,</span></div><div style="font-size:small"><br></div><div style="font-size:small">Regards,</div><div style="font-size:small">Hunor </div></div>
</blockquote></div></div>