Hyphenated keywords and switch expressions

[Brian Goetz]

> On Jan 11, 2019, at 5:19 AM, Ben Evans <benjamin.john.evans at gmail.com> wrote:
> 
> Hi EG members,
> 
> I had a couple of comments on hyphenated keywords.
> 
> First off, I think they're a great idea, if used judiciously.

Right.  Judging from the twitter response, you'd think people thought we were running a contest for the next seven hundred keywords … but this is really just about giving us reasonable choices for features that are already in the works.  

> Secondly, a question. Is it worth reconsidering the choice of keyword
> used for switch expressions with hyphenation in mind?

It’s a great question — but in this case I don’t see it.  Early in the design process, we were concerned that `switch` was so irregular that we were never going to be able to rehabilitate it to handle patterns, to be an expression, and to support the desired scoping rules for pattern matching.  And if that were the case, we’d want to consider using another linguistic form for matching, or for expressions.  But we never wanted to split switch; discussions on doing so were more about the fear we might have to, than the desire to do to.  And, lo and behold, after more than a year of patiently chipping away at the various issues, we managed to find a generalization of switch that works cleanly as both expression and statement, that generalizes to patterns cleanly, and a set of scoping rules that tames switch’s scoping.  We were pleasantly surprised, but we’ll take the win. 

The only remaining asymmetries between switch statement and expression now are: 
  - Switch expressions must be total (because expressions are total), but switch statements must be allowed to be partial (because they always have been so).  
  - (future) If we ever manage to make `void` into a type, then it would be nice if a void switch expression and a switch statement were actually the same thing.  

The lack of exhaustiveness checking for switch statements is a bummer, and at some point, we might consider allowing users to opt back in for statements (`switch-exhaustively`), but for now, I think giving the expression form and statement forms two different names is more confusing than helpful.  

The change I think we should consider in light of our newfound keyword supply is `break`.  Reusing `break value` as a way of yielding a value from a switch was the sort of “ten pounds in a five pound bag” move that we have historically been forced to make, and “break with value” and “break to label” are actually different concepts, and so more deserving of different names than “switch with side effects” and ‘switch with return value.”  And readers will have to look carefully at `break foo` to determine whether `foo` is a label or a variable.  

My current favorite for this is `break-with v`.  

> 1. switch is only legal in statement form (the current Java 11 behaviour)
> 2. switch-expr is only legal for the expression form
> 
> To my mind, this helps in a few ways:
> 
> a) It maintains the cognitive connection between switch expressions
> and switch statements, and doesn't lead to the feeling that switch
> statements are abandonware
> b) It provides a clear clue to newcomers about the distinction between
> the two forms (bear in mind that beginners often don't develop a full
> grasp of the distinction between statements and expressions until they
> have gained some proficiency with the language. The differentiation of
> the keyword could help provide visual clues and avoid
> hard-to-understand-if-you're-a-newbie compiler errors when debugging)
> c) There is no cognitive overhead for experienced programmers.
> d) IDEs will easily be able to autodetect and offer to correct if the
> wrong keyword is used "Did you mean switch-expr instead of switch?”

I think (a)/(b) is mostly “Stroustrup’s Rule” in action; the perception that switch expressions are new, and so they need a new and different looking syntax.  But after you’ve been programming with both for more than ten minutes, I suspect the distinction will be more distracting than helpful — and merely one more opportunity to make a mistake and have the compiler yell at you.  (And, the distinction between expressions and statements is not one that newbies have front-and-center in their minds; this is something that experienced developers, and language designers, are more conscious of.)