So, from a language design perspective, 'return x' is wrong - but, as
you point out, we already committed the original sin of having 'return
== local return' for lambdas, so I'm not too convinced that we couldn't
use the same story again here. E.g. when you say 'return', what you
really mean is 'returning from the innermost context'. This could be a
method (as usual), or a nested expression e.g. a lambda or a switch
expression.
Kevin has a point in that using return is mildly worrisome when it comes
to refactoring; but we had exactly the same problem with lambdas when we
were considering migrating code using internal iteration (for loop) to
code using external iteration (Stream forEach) - again, there the
refactoring could not be 100% smooth - if the body of your loop had some
abnormally completing branches, then there was no way to translate that
into an external iteration idiom - at least not mechanically (e.g.
'return x' already meant something different inside old-style for loop
bodies).
So, seems to me that we end up with the same bag of pros and cons? E.g.
more familiar to the user (return <expr> is something that they know and
love), but more smelly from a design point of view (in a way that
forecloses using 'return' to mean non-local return, but I wonder - has
that ship already sailed?)
Maurizio
On 15/03/18 18:11, Brian Goetz wrote:
On 3/14/2018 2:04 PM, Kevin Bourrillion wrote:
On Wed, Mar 14, 2018 at 8:14 AM, Brian Goetz <brian.go...@oracle.com
<mailto:brian.go...@oracle.com>> wrote:
In the meantime, let me probe for what's really uncomfortable
about the current design point. Is it:
- That we are overloading an existing control construct,
"break", to mean something just different enough to be uncomfortable;
To some degree yes, since `break <identifier>` already means something.
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.)
