On 14 Jan 2019, at 21:40, Alex Buckley <alex.buck...@oracle.com>
wrote:
Hi Gavin,
Some points driven partly by the discussion with Tagir:
1. In 14.11.1, SwitchLabeledBlock should not end with a `;` --
there is no indication in JEP 325 that a semicolon is desired after
`-> {...}` and javac in JDK 12 does not accept one there. Also,
SwitchLabeledThrowStatement should not end with a `;` because
ThrowStatement includes a `;`.
2. In 14.11.1, "This block can either be empty, or take one of two
forms:" is wrong for switch expressions. The emptiness allowed by
the grammar will be banned semantically in 15.29.1, so 14.11.1
should avoid trouble by speaking broadly of the forms in an
educational tone: "A switch block can consist of either: - _Switch
labeled rules_, which use `->` to introduce either a _switch
labeled expression_, ..." Also, "optionally followed by switch
labels." is wrong for switch expressions, so prefer: "- _Switch
labeled statement groups_, which use `:` to introduce block
statements."
3. In 15.29.1: (this is mainly driven by eyeballing against
14.11.2)
- Incorrect Markdown in section header.
- The error clause in the following bullet is redundant because the
list header already called for an error: "The switch block must be
compatible with the type of the selector expression, *****or a
compile-time error occurs*****."
- I would prefer to pull the choice of {default label, enum typed
selector expression} into a fourth bullet of the prior list, to
align how 14.11.2's list has a bullet concerning default label.
- The significant rule from 14.11.2 that "If the switch block
consists of switch labeled rules, then any switch labeled
expression must be a statement expression (14.8)." has no parallel
in 15.29.1. Instead, for switch labeled rules, 15.29.1 has a rule
for switch labeled blocks. (1) We haven't seen switch labeled
blocks for ages, so a cross-ref to 14.11.1 is due. (2) A note that
switch exprs allow `-> ANY_EXPRESSION` while switch statements
allow `-> NOT_ANY_EXPRESSION` is due in both sections; grep ch.8
for "In this respect" to see what I mean. (3) The semantic
constraints on switch labeled rules+statement groups in 15.29.1
should be easily contrastable with those in 14.11.2 -- one approach
is to pull the following constraints into 15.29.1's "all conditions
true, or error" list:
----- - If the switch block consists of switch labeled rules, then
any switch labeled block (14.11.1) MUST COMPLETE ABRUPTLY. - If the
switch block consists of switch labeled statement groups, then the
last statement in the switch block MUST COMPLETE ABRUPTLY, and the
switch block MUST NOT HAVE ANY SWITCH LABELS AFTER THE LAST SWITCH
LABELED STATEMENT GROUP. -----
If you prefer to keep these semantic constraints standalone so that
they have negative polarity, then 14.11.2 should to the same for
its significant-but-easily-missed "must be a statement expression"
constraint.
Alex
On 1/13/2019 2:53 AM, Tagir Valeev wrote:
Hello!
I'm concerned about any claim of ambiguity in the grammar,
though I'm not sure I'm following you correctly. I agree that
your first fragment is parsed as two statements -- a switch
statement and an empty statement -- but I don't know what you
mean about "inside switch expression rule" for your second
fragment. A switch expression is not an expression statement
(JLS 14.8). In your second fragment, the leftmost default label
is followed not by a block or a throw statement but by an
expression (`switch (0) {...}`, a unary expression) and a
semicolon.
Ah, ok, we moved away slightly from the spec draft [1]. I was
not aware, because I haven't wrote parser by myself. The draft
says:
SwitchLabeledRule: SwitchLabeledExpression SwitchLabeledBlock
SwitchLabeledThrowStatement
SwitchLabeledExpression: SwitchLabel -> Expression ;
SwitchLabeledBlock: SwitchLabel -> Block ;
SwitchLabeledThrowStatement: SwitchLabel -> ThrowStatement ;
(by the way I think that ; after block and throw should not be
present: current implementation does not require it after the
block and throw statement already includes a ; inside it).
Instead we implement it like:
SwitchLabeledRule: SwitchLabel -> SwitchLabeledRuleStatement
SwitchLabeledRuleStatement: ExpressionStatement Block
ThrowStatement
So we assume that the right part of SwitchLabeledRule is always
a statement and reused ExpressionStatement to express Expression
plus semicolon, because syntactically it looks the same. Strictly
following a spec draft here looks even more ugly, because it
requires more object types in our code model and reduces the
flexibility when we need to perform code transformation. E.g. if
we want to wrap expression into block, currently we just need to
replace an ExpressionStatement with a Block not touching a
SwitchLabel at all. Had we mirrored the spec in our code model,
we would need to replace SwitchLabeledExpression with
SwitchLabeledBlock which looks more annoying.
With best regards, Tagir Valeev
[1]
http://cr.openjdk.java.net/~gbierman/switch-expressions.html#jep325-14.11
