I think there are good arguments on both sides of this issue. Because,
expression switch and statement switch, they have both commonality and
difference.
Overall, my gut sense is that "lumping" is better than "splitting"
here. Especially as there are so many possible dimensions of lump vs
split: expression vs statement, constants vs patterns, exhaustive vs
not, fallthrough vs not, colons vs arrows, etc.
Your point about "people of the future" is a good one. When a "Java 9
person" encounters expression switch for the first time, the lumping may
help (or might make it harder) to understand the commonalities vs
differences. On the other hand, a "Java 15 person" looking back in
history may have a different perspective, and we should design for the
future person as being a newbie is (hopefully) a short-lived experience.
So, for where we want to land, does it make more sense to accentuate the
commonality ("do exactly one of these things, based on these choices")
or the difference ("operate via side-effects vs computation")? My sense
is the former, but others may have different opinions.
On 12/14/2017 5:59 PM, Remi Forax wrote:
but i still think we should no have the same keyword for the switch
and the expression switch (so we will not name i the expression
switch), whatever keyword is fine for me but not switch, it's not the
same semantics.
