JEP325: Switch expressions spec

[Dan Smith]

> On May 10, 2018, at 6:28 AM, Gavin Bierman <gavin.bierman at oracle.com> wrote:
> 
>> SwitchStatementClause is probably too general. I don't think we want to allow arbitrary statements to occur on the RHS without braces. It's unweildy (think about a chain of if-else, for example), inconsistent with others uses of "->", and ambiguous: does "case foo -> switch (expr) { ... }" describe a switch statement or a switch expression?
> 
> Actually the opposite was argued for - that requiring braces would be too much clutter. It is inconsistent with statement lambda though, as you point out.

Here's a roughly-prioritized list of reasons I think allowing an arbitrary statement after '->' is bad:

- There's a grammatical ambiguity between "-> SwitchStatement" and "-> SwitchExpression"
- It's inconsistent with SwitchExpression (which does not allow a statement after the arrow)
- It allows lots of confusing constructs, like "case Foo -> bar: if (cond) m();"
- It's inconsistent with LambdaExpression

The last three are subjective complaints, YMMV.

>> I also have concerns about the heavy duplication between the specs for switch statements and switch expressions. Wasn't this design motivated by wanting to have a single, unified construct packaged in expression and statement forms?
> 
> At the time it was felt that the symmetry was not what was wanted. The new forms of case labels would strongly push the user to the comma separated form, rather than the multiple case label form. Allowing both forms seems messy. But I think it’s a matter of taste. [You will have read Guy’s emails on this elsewhere also.]

Wrong dimension.

I endorse separate arrow and colon switch body productions.

I'm saying I'd like to avoid separate expression and statement switch body productions.

>> With or without 'null', there's a good argument that the arrow clauses need a way to syntactically combine specific cases and 'default'. Where are we at on this?
> 
> We’ve dropped null patterns for now. 

That's why I said "with or without 'null'". :-)

I think people will miss "case 3, 4, default ->" (or the equivalent) if we don't give it to them, and maybe end up shifting to the colon body syntax as a workaround.

It's not crucial, though.

>> Throughout: for other specs, people have expressed interest in seeing a complete before-and-after diff. No shortcuts. (And they're probably right—it's a lot easier to see what's going on that way.) So any words that have been removed should be indicated explicitly as deletions, rather than just leaving the old words out and highlighting the new words as additions.
> 
> I started with doing just the diff, but as so many changes were being made it started looking rather unhelpful, so I went with the “here’s what the section will look like” with the additions and deletions there. I tried to flag all deletions - but sounds like I might have missed a few. 

Not clear to me what you mean by "just the diff" (maybe output from an automated tool?). What I'm describing is that while it's sometimes a helpful shortcut to do this:

A **widget** is a kind of expression

Readers want to see the removal, too:

A ~~wingding~~ **widget** is a kind of expression

Sometimes this gets fiddly, and I find it easiest to strikeout a whole sentence or paragraph, then insert the new and improved version, even though there are some shared words. So, yes, exercise editorial discretion in deciding how to present things. But a reader should be able to reconstruct the original section text using only what you've given them.

>> 14.11: somewhat arbitrarily, '->' is considered an "operator" while ':' is considered a "separator". Should match that terminology.
> 
> Where is ‘:’ called a separator? I used the word ‘operator’ which is the terminology from JLS§3.12. I’d be happy to use other terminology (I wanted to avoid saying token.)

My mistake, I misread section 3.11.

>> 14.11: Use of the term "pattern" is premature. These are really just ConstantExpressions (plus, maybe, null). As is, we have lots of undefined concepts: When is a pattern "assignment compatible with" a type? When does a pattern "have the same value" as another?
> 
> Yes, I wanted to start weaving in pattern terminology ahead of time. On reflection maybe it’s not the right thing to do. [As an aside, I think it’s pretty obvious what the definition of the “undefined” concepts are. Don’t we do a similar pun with constant expressions and expressions? For example, do we define a notion of value for constant expressions distinct from expressions?]

Okay, fair. As long as "pattern" refers to a subset of "expression", maybe you can get away with that.

>> 14.11 "A Java compiler is encouraged": after much discussion about exhaustiveness, I think the consensus is that we would very much not like for a Java compiler to do this. Silently doing nothing for some inputs is a feature of switch statements.
> 
> Hmm…That’s old text that predates this JEP. 

Yes, but we have scrutinized it a lot when developing this feature, and agreed that it was misguided.

>> 14.11 "If multiple statements are needed then a block (14.2) should be used": this is a useful illustration, but in the context of Chapter 14, probably too chatty. It's a given that a Block can be used wherever you want multiple statements. Compare the spec for the 'while' loop (14.12).
> 
> Ok. That was an explicit request but I’ll take another look.

This is always subjective. There is a tendency, which I'm trying to guard against, of over-explaining new features while assuming everyone intuitively understands old features. We want the finished document to feel cohesive to someone with fresh eyes. But sometimes the old features could use a little more discussion, too!

>> 15.29 "the switch expression completes normally": More conventionally, "the value of the switch expression is …"
> 
> That phrase occurs in several places, so you’ll have to tell me which one you don’t like. 

"If execution of the Statement completes abruptly for the reason of a break with a value, then the switch expression completes normally with that value."

I'd suggest changing to "for the reason of a break with a value _V_, then the value of the switch expression is _V_."

For comparison, in all of Chapter 15, I only find four usages of the phrase "complete[s] normally". Lots of usages of "complete[s] abruptly", though. Switch _bodies_ are special, because they contain statements, so it makes sense to say "completes normally" here. But once we've left the body and we're talking about the switch expression as a whole, it's better to use the expression-oriented terminology.