Expression switch feedback

Some feedback on expression switches (from having to write a presentation about Project Amber features). The model being used for expression switches is that they are just switches with a few enhancements. I'm uncomfortable with this for a number of reasons. 1) Personally I find the following to be deep flaws in statement switch: - fall through by default - a source of bugs and confusion - case clauses that act like blocks but without their own scope, such that variable declarations clash with other cases (hit me again today) I fully understand the reluctance to create a second switch-like language feature. But it seems to me that these two problems can be designed out without expression switch being completely different. (The only use case for fall through I ever see presented is low level network code, which is very much an edge case. Is there some use case in pattern matching for fall through that I am unaware of?) 2) Normally when adding a new feature the desire is to add the feature in a way that will makes sense viewed 10 years hence. However the current explanation for expression switch is couched in terms of 'its just the same old statement switch with a few new extras'. This gives the appearance of being a design for existing developers migrating, rather than a strong design for the longer term. 3) Expression switch is unlike any other kind of element in the language, and this is causing rough edges. It is not especially like a "normal" expression, nor like a "normal" statement or method. While expressions in Java can be large, they are generally relatively small. The largest expressions (and I think the only ones with curly braces) are inner classes and block lambdas, both of which define method-like constructs with very clear method-like scoping and semantics. With the current proposal, we have curly braces inside expressions where they are not methods, and those braces have impacts on use of the return keyword for example. It will also be tricky to explain in 10 years time why if..else has ternary as its expression counterpart, but switch is both statement and expression. 4) The context as to whether it is an expression or statement has the potential to be too remote and impact reading/writing code. The problem is most apparent with return. The current proposal is to disallow return within expression lambdas (a reasonable choice, although I'm not 100% convinced of it). The problem is that switch statements tend to be large, and the is no reason why expression switches would not also be large (since blocks are allowed). Specifically, it is not uncommon for a switch statement to be longer than the vertical editor space, and thus you may be reading code in the middle of a switch without context of whether it is a statement or an expression switch. // lots of code case FOO: if (bar == null) { return "str"; // is this allowed or not? } // lots more code This is only allowed in a statement switch, yet because switches can be large, the context as to whether it is a statement or expression switch cannot be seen, ie. the context that determines code validity is too remote. Some other more positive thoughts: 1) The addition of "case null" seems simple to understand and explain 2) The addition of comma separated cases also seems simple to understand and explain 3) The use of "break expression" seems generally to be fine, I'm not too concerned about the interaction with "break label". However, I would ask for consideration to allow "break :label" and "continue :label" (a colon before the label) to be valid syntax, so that over time developers could transition to a clearer way to express labelled breaks distinct from expression breaks. 4) The automatic default clause for enums seems good and desirable, but it will be odd not having it in statement switches. Finally, as far as I can tell, the following is legal in the current proposal. Is this true?: var action = switch (trafficLight) { case RED: System.out.println("Found red"); // fallthru case YELLOW -> "Stop"; case GREEN: System.out.println("Found green"); break "Green"; } (I find this mixture of expression and statement styles complex and ugly) Rather than complicate this mail, I'll follow up separately with my thoughts on what I'd change in the current proposal. Stephen