[
https://issues.apache.org/jira/browse/GROOVY-12399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12399:
-------------------------------
Description:
Since GROOVY-12255 (first-class switch expressions), a {{switch}} used as a
*statement* is only rewritten to a {{SwitchStatement}} when an arrow arm is a
block that does not {{yield}}. A single expression arm, or a block containing
exactly one expression statement, becomes an implicit {{yield}} and the switch
stays a {{SwitchExpression}} even though its value is discarded. Such a switch
now inherits the expression rules: an unmatched selector throws
{{IllegalStateException}} in dynamic code and a missing {{default}} is a
compile error under {{@TypeChecked}} / {{@CompileStatic}}.
{code:groovy}
def f(Object o) {
def r = 'none'
switch (o) {
case String -> r = 'str'
}
r
}
f(42)
{code}
Groovy 5.1.2: returns {{'none'}}. Groovy 6.0.0-RC-1:
{noformat}
java.lang.IllegalStateException: the switch expression does not cover the value
42
{noformat}
With {{@TypeChecked}} on {{f}}:
{noformat}
the switch expression does not cover all possible input values
{noformat}
The boundary depends on arm shape rather than position, which shows it is not
intended:
{code:groovy}
switch (o) { case String -> r = 'str' } // throws when unmatched
switch (o) { case String -> { r = 'str' } } // throws when unmatched
switch (o) { case String -> { r = 'str'; r += '!' } } // fine
switch (o) { case String -> { if (o) r = 'str' } } // fine
switch (o) { case String: r = 'str' } // fine
{code}
h3. Background
In Java (JEP 361) the arrow is not what makes a switch an expression: both
switch statements and switch expressions may use either the arrow or the colon
form. The arrow controls fall-through; the position controls whether a value is
produced. A Java switch statement with arrow arms needs no {{default}} and does
nothing when unmatched (exhaustiveness is only required for statements that use
patterns or {{case null}}, JEP 441).
Groovy's implementation grew up with the other reading. GROOVY-9272 (4.0) added
the arrow form _as_ the switch expression: the grammar rule is
{{switchExpression}}, it accepts only arrows, and a switch in statement
position was simply a switch expression whose value nobody read. That was
harmless while the lowering was a closure call that evaluated to {{null}} when
nothing matched. GROOVY-12255 kept "arrow means expression", gave expressions
real semantics (exhaustiveness, the unmatched throw) and added a statement
rewrite only for the one shape that visibly broke, blocks without {{yield}}.
The GROOVY-12255 compatibility notes describe the new behaviour for switch
_expressions_ only and state that a switch used as a statement is a
{{SwitchStatement}}; the statement-position tests in {{Groovy12255.groovy}} all
carry a {{default}} or always match, so the unmatched case was never exercised.
h3. Proposed fix
Classify by position rather than syntax, as Java does: in statement position
always build a {{SwitchStatement}}, whatever the arm shape
({{isSwitchUsedAsStatement}} already identifies the position). The
exhaustiveness error and the unmatched-selector throw stay reserved for
switches whose value is used.
One case needs a decision: a switch as the last statement of a method body is
an implicit return value. 4.x/5.x returned the matched arm's value, or {{null}}
when unmatched. Keeping it an expression preserves the value but throws when
unmatched; treating it as a statement returns {{null}} in both cases.
was:
Since GROOVY-12255 (first-class switch expressions), a {{switch}} used as a
*statement* is only rewritten to a {{SwitchStatement}} when an arrow arm is a
block that does not {{yield}}. A single expression arm, or a block containing
exactly one expression statement, becomes an implicit {{yield}} and the switch
stays a {{SwitchExpression}} even though its value is discarded. Such a switch
now inherits the expression rules: an unmatched selector throws
{{IllegalStateException}} in dynamic code and a missing {{default}} is a
compile error under {{@TypeChecked}} / {{@CompileStatic}}.
{code:groovy}
def f(Object o) {
def r = 'none'
switch (o) {
case String -> r = 'str'
}
r
}
f(42)
{code}
Groovy 5.1.2: returns {{'none'}}. Groovy 6.0.0-RC-1:
{noformat}
java.lang.IllegalStateException: the switch expression does not cover the value
42
{noformat}
With {{@TypeChecked}} on {{f}}:
{noformat}
the switch expression does not cover all possible input values
{noformat}
The boundary depends on arm shape rather than position, which shows it is not
intended:
{code:groovy}
switch (o) { case String -> r = 'str' } // throws when unmatched
switch (o) { case String -> { r = 'str' } } // throws when unmatched
switch (o) { case String -> { r = 'str'; r += '!' } } // fine
switch (o) { case String -> { if (o) r = 'str' } } // fine
switch (o) { case String: r = 'str' } // fine
{code}
The GROOVY-12255 compatibility notes describe the new {{IllegalStateException}}
and the exhaustiveness error for switch _expressions_ only, and state that a
switch used as a statement is a {{SwitchStatement}}. The statement-position
tests in {{Groovy12255.groovy}} all carry a {{default}} or always match, so the
unmatched case was never exercised.
h3. Proposed fix
In statement position always build a {{SwitchStatement}}, whatever the arm
shape ({{isSwitchUsedAsStatement}} already identifies the position). The
exhaustiveness error and the unmatched-selector throw stay reserved for
switches whose value is used.
One case needs a decision: a switch as the last statement of a method body is
an implicit return value. 4.x/5.x returned the matched arm's value, or {{null}}
when unmatched. Keeping it an expression preserves the value but throws when
unmatched; treating it as a statement returns {{null}} in both cases.
> Arrow switch statement without default throws IllegalStateException when no
> arm matches
> ---------------------------------------------------------------------------------------
>
> Key: GROOVY-12399
> URL: https://issues.apache.org/jira/browse/GROOVY-12399
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 6.0.0-RC-2
> Reporter: Paul King
> Priority: Major
>
> Since GROOVY-12255 (first-class switch expressions), a {{switch}} used as a
> *statement* is only rewritten to a {{SwitchStatement}} when an arrow arm is a
> block that does not {{yield}}. A single expression arm, or a block containing
> exactly one expression statement, becomes an implicit {{yield}} and the
> switch stays a {{SwitchExpression}} even though its value is discarded. Such
> a switch now inherits the expression rules: an unmatched selector throws
> {{IllegalStateException}} in dynamic code and a missing {{default}} is a
> compile error under {{@TypeChecked}} / {{@CompileStatic}}.
> {code:groovy}
> def f(Object o) {
> def r = 'none'
> switch (o) {
> case String -> r = 'str'
> }
> r
> }
> f(42)
> {code}
> Groovy 5.1.2: returns {{'none'}}. Groovy 6.0.0-RC-1:
> {noformat}
> java.lang.IllegalStateException: the switch expression does not cover the
> value 42
> {noformat}
> With {{@TypeChecked}} on {{f}}:
> {noformat}
> the switch expression does not cover all possible input values
> {noformat}
> The boundary depends on arm shape rather than position, which shows it is not
> intended:
> {code:groovy}
> switch (o) { case String -> r = 'str' } // throws when unmatched
> switch (o) { case String -> { r = 'str' } } // throws when unmatched
> switch (o) { case String -> { r = 'str'; r += '!' } } // fine
> switch (o) { case String -> { if (o) r = 'str' } } // fine
> switch (o) { case String: r = 'str' } // fine
> {code}
> h3. Background
> In Java (JEP 361) the arrow is not what makes a switch an expression: both
> switch statements and switch expressions may use either the arrow or the
> colon form. The arrow controls fall-through; the position controls whether a
> value is produced. A Java switch statement with arrow arms needs no
> {{default}} and does nothing when unmatched (exhaustiveness is only required
> for statements that use patterns or {{case null}}, JEP 441).
> Groovy's implementation grew up with the other reading. GROOVY-9272 (4.0)
> added the arrow form _as_ the switch expression: the grammar rule is
> {{switchExpression}}, it accepts only arrows, and a switch in statement
> position was simply a switch expression whose value nobody read. That was
> harmless while the lowering was a closure call that evaluated to {{null}}
> when nothing matched. GROOVY-12255 kept "arrow means expression", gave
> expressions real semantics (exhaustiveness, the unmatched throw) and added a
> statement rewrite only for the one shape that visibly broke, blocks without
> {{yield}}. The GROOVY-12255 compatibility notes describe the new behaviour
> for switch _expressions_ only and state that a switch used as a statement is
> a {{SwitchStatement}}; the statement-position tests in {{Groovy12255.groovy}}
> all carry a {{default}} or always match, so the unmatched case was never
> exercised.
> h3. Proposed fix
> Classify by position rather than syntax, as Java does: in statement position
> always build a {{SwitchStatement}}, whatever the arm shape
> ({{isSwitchUsedAsStatement}} already identifies the position). The
> exhaustiveness error and the unmatched-selector throw stay reserved for
> switches whose value is used.
> One case needs a decision: a switch as the last statement of a method body is
> an implicit return value. 4.x/5.x returned the matched arm's value, or
> {{null}} when unmatched. Keeping it an expression preserves the value but
> throws when unmatched; treating it as a statement returns {{null}} in both
> cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
