break seen as a C archaism

[John Rose]

On Mar 15, 2018, at 11:11 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> We had rejected this earlier for fairly obvious reasons, but let me
> ask to get a subjective response: would using "return x" be better?
> On the one hand, it's not really a return, and it doesn't build on the
> user intuition about the control flow aspects of break, but on the
> other, the return statement is already prepared to take a value, so
> its not adding a "new form" to the existing statement, though it is
> adding a new and different context.  (We abuse it slightly in lambdas,
> but people seem OK with this, probably because they think of lambdas
> as methods anyway.)

Here's my take on how this is going, for what it's worth.

We're going round and round on this because there's isn't a comfortable
spot to land.  But there is a nearly comfortable spot, which is where we
started:  Although break's legacy syntax requires an overload for it to
accept a value, the following two legacy facts pull us toward break:
  - break is to switch as return is to a method body (in branch behavior)
  - return is a branch which can be overloaded with an optional value
Now, switches are becoming more like methods: They can return values.
So the most direct path is to overload break "like return", in some way.
What way?  Well, the straightforward way works, with the usual tricks
to avoid ambiguities in overloaded constructs.  At that point we have
added to the language by increasing symmetry, a win.

Let's beware of making new language features #{ Stand Out }.  It makes
them look silly and puzzling when they mature.  Many objections to
novelties like "break x" are of two potential kinds:  a. "I want the new
thing to be easier to spot", b. "Programmers will never be at ease with
that".  People tend to use a. as a proxy for b., but as we go round
and round I think many of us tend to forget about b., which is the
real point.  Can anyone successfully argue that "break x" liable to b.?
I doubt it.

Our quest for continuity and symmetry with the past is our best
trick for avoiding b. (and c., "Let's fork the language"), even at
the temporary cost of a.

Neal Gafter says it very well:
> It is better to design the feature so that it fits well with the existing
> features of the language, even if it might at first seem jarring that
> things have changed. Users will quickly get over the newness of
> the changes and learn to understand the language as a whole as
> it is (after the change).

The adding of -> to the mix is an inspired move (thanks, Brian)
because it repurposes another existing part of the language,
and adds it as sugar for "break x", keeping continuity and
improving clarity at the same time.

My $0.02.

— John

P.S. FTR here's the reference to Neal's blog:
http://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html

P.P.S. The above reasoning might lead to other places too:  If we were to
make loops return values, then "break" would do the same for them.
Also "continue" could be overloaded to deliver a partial result to the
loop control.  That's sci fi at the present moment, but I'm showing it as
an example how the logic works.