Call for feedback -- switch expressions in JDK 12
Dan Smith
daniel.smith at oracle.com
Tue May 7 02:01:46 UTC 2019
> On Apr 28, 2019, at 5:37 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
>
> Other related concepts that don't exactly align with switch statement with ->:
> - lambdas can be void compatible and/or value compatible.
> This concept *could* be applied to switch also, but isn't.
Lambda expressions have a unique problem: a particular lambda expression could be interpreted with respect to different target types, some of which have void returns and others of which have value returns. As an early way to characterize which sorts of target types it could be compatible with, we can identify a lambda body as value-compatible, void-compatible, or both. (Or neither, which is an error.)
Method bodies don't have this problem: it's known up front whether a method is void or not, so we can proceed to check the body with that context firmly fixed. There's no such thing as a "void-compatible" method body.
Switch statements/expressions are more like methods than like lambdas: we know based on enclosing syntax whether we're looking at a switch statement or a switch expression, so we can directly state rules about whether 'break-with' or 'break' should be used, and whether the block can complete normally.
I don't think it would be useful to try to approach switch blocks in the same context-independent way we treat lambda bodies.
> - we already have the concept of ExpressionStatement/StatementExpression,
> for things that swing both ways, but switch does not participate in this, either.
I think I noticed the rule is missing when reviewing the latest spec document, but the intent is: syntactically, a SwitchLabeledExpression is 'SwitchLabel -> Expression ;'. As an additional rule, in the context of a SwitchStatement, all the SwitchLabeledExpressions must be StatementExpressions. This is much the same way a lambda body with an expression form is checked for compatibility with a void return (15.12.2.1).
Is that what you're referring to?
More information about the jdk-dev
mailing list