break seen as a C archaism

[Victor Nazarov]

On Wed, Mar 14, 2018 at 4:38 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> There are three arguments why the N case is significantly different from
> the 2 case.
>
> There are a number of idioms that require statements in addition to an
> expression.  Debugging printfs, objects that take statements to initialize
> (construct/set/set/break), incrementing counters, cases that require side
> conditions (if today is tuesday do one thing, otherwise another), etc.
> Each individually is rare-ish, but not all that rare.
>
> The "static applicability" argument is that the larger the number of
> cases, the more likely one of them will fall into one these buckets, and
> then the  whole thing has to fall back to statements.  This makes
> expression switches less useful, and falling off this cliff is likely to
> irritate users every time it happens.
>
> The “dynamic applicability” argument is that, if you want to change an
> existing switch (say, to add a debugging printf in one path), you have to
> refactor the whole thing.  Which will be met, by users, with “YGBFKM.”
>
> The “cliff height” argument says that falling off the cliff on a two-way
> conditional and having to refactor to if-else is far less painful than
> falling off the cliff on an N-way switch.  Its a more painful refactor.
>

As someone who participated in bringing this topic back to attention I'd
like to say that I personally find these arguments substantial and
persuasive. I think it's enough to bring me peace considering current
switch-expression proposal (with restriction that we can't jump to a label
outside switch block).
The only argument against left is

I think that there are features that make sense on their own, and there are
> features that *totally make lots of sense* assuming that you have heard the
> expert group's passionate explanation of why they make sense. (It reminds
> me of a certain Pied Piper focus group near the end of Silicon Valley
> season 2, but moving on.) I am concerned that "breaking a value" is of the
> second kind."
>

But this is not technical argument and I think it can't overweight
technical ones.

--
Victor Nazarov