break seen as a C archaism
brian.goetz at oracle.com
Wed Mar 14 15:14:54 UTC 2018
> I hope the point was still received that embedding statements inside
> an expression for immediate evaluation appears to be novel for Java.
> (All else being equal I assume that we are seeking to minimize novelty.)
Yes, we're seeking to minimize unnecessary novelty. Winning is making
things look like they were there all along. (Sometimes we do better on
this score than others; I don't hold out a lot of hope for "break n"
being immediately recognized as something that was always lurking under
the surface, especially given how much people hate break already, but I
think we'll do pretty well on this score for integrating patterns in
I think a sensible next step would be for me to summarize the path by
which we got here. I'll try to write that up in the next few days.
In the meantime, let me probe for what's really uncomfortable about the
current design point. Is it:
- That there are two ways to yield a value, -> e and "break e", and
users won't be able to keep them straight;
- The idea of using a statement at all to yield a value from an
expression seems too roundabout;
- That we are overloading an existing control construct, "break", to
mean something just different enough to be uncomfortable;
- Something else?
More information about the amber-spec-observers