Disallowing break label (and continue label) inside an expression switch
kevinb at google.com
Fri Mar 23 20:18:45 UTC 2018
Just want to echo that I think prohibiting labeled break from e-switch is
great for *both* reasons - keeping expressions functional in nature,
the ambiguity in the argument after `break`. Strong +1.
On Fri, Mar 23, 2018 at 12:58 PM, Brian Goetz <brian.goetz at oracle.com>
> I think the burden should go the other way -- we should justify why such
> flexibility is warranted, and I think this is difficult to do.
> The conditions under which such control flow are useful are already small,
> and further, when you might want to code like that, the expression switch
> form offers relatively little benefit over expression statements anyway
> (since by definition you're using a lot of control-flow statements to make
> your complex control-flow decision.) In exchange, the cost on all readers
> is high, because they can't be sure about what "break X" means. Why burden
> all users with this complexity? Why spend any of our complexity budget on
> such a low-leverage option?
> On 3/23/2018 3:53 PM, John Rose wrote:
> On Mar 23, 2018, at 12:41 PM, Brian Goetz <Brian.Goetz at Oracle.COM> wrote:
> I think so. Its not detecting the ambiguity, its that the possibility of
> mixing control flow kinds means the poor reader has to reason about all the
> possibilities, and not be sure what "break FOO" means in a switch statement.
> A lighter fix, then, would be to require parentheses always.
> An even lighter fix would be leave that kind of clarification to style
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the amber-spec-observers