> On May 10, 2018, at 6:28 AM, Gavin Bierman <gavin.bier...@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.
