These restrictions are a straightforward refinement of the scoping rules presented earlier.Ī more limited form of fallthrough is OR patterns: case P1 || P2: The binding variable y would not be available in s, because we can’t rely on it having a value on all control paths, but x can still be available in s.
This is analogous to the disjunction y matches Foo(int x) || y matches Bar(int x).
However, there’s no reason why we can’t make this work, with x in scope in s: case Foo(int x): Would be an error, just as x matches Foo(int x) || x.matches Bar(float x) would be. Patterns that generate binding variables require some refinements to the above scoping rules. While one could make an argument that fallthrough in switch was the wrong default, the problem fallthrough aims to solve - treating multiple items similarly without duplicating the code - were real, and are still relevant when our case labels get richer. Similarly, for intersect, it is an error if the same binding variable is present in both sets but with different types. The union function should be a disjoint union: it is an error if any binding varible is present in both sets - otherwise, expressions like x matches Foo(var x) & y matches Bar(var x) would include two different variables called x in the same scope. The situation of having variable declarations arise from expressions is new, so it is a reasonable question to ask “What is the scope of of a binding variable of a pattern match?” There’s also an obvious answer - the scope of the statement that encloses the pattern match we can just hoist variables into the scope which includes the statement which includes the match expression: if (x matches String s) include binding variables from P in yįurther, union and intersection should be limited to avoid conflicts. ScopingĪ switch statement today is one big scope the “arms” of a switch do not constitute individual scopes, unless scoping constructs (such as introducing a new block) are explicitly used by the author. We can use this duality as a lens through which to evaluate the regularity of extensions to switch. It should be noted that there is a duality between switch statements and a chain of if-else statements. Under what conditions might a switch expression without a default clause be considered exhaustive? What is the scope of binding variables introduced in pattern case labels?ĭoes fallthrough need to be restricted to make sense with pattern case labels?Ĭan switch be smoothly extended to an expression, and if so, what changes need to be made?ĭo we need additional control flow constructs, like break or continue?ĭo we need “guard” conditions on patterns? While its range was extended several times (switching on enums in Java 5, and strings in Java 7), the basic facility is largely unchanged from C.Īs we consider extending switch to support a wider variety of types, and case labels to support patterns, it raises some new questions, such as: It was designed as a limited mechanism for limited situations one can only switch on a small set of types, and one can only have case labels that exactly match literal constants.
Java inherited its switch construct nearly wholesale from C. Pattern Matching in the Java Object model - Explores how patterns fit into the Java object model, how they fill a hole we may not have realized existed, and how they might affect API design going forward. Type Patterns in Switch - A more up-to-date treatment of extending pattern matching to switch statements, including treatment of nullity and totality. Pattern Matching For Java - Semantics - More detailed notes on type checking, matching, and scoping of patterns and binding variables.Įxtending Switch for Patterns (this document) - An early exploration of the issues surrounding extending pattern matching to the switch statement. Pattern Matching For Java - Overview of pattern matching concepts, and how they might be surfaced in Java. This is an exploratory document only and does not constitute a plan for any specific feature in any specific version of the Java Language. This document explores a possible direction for enhancements to switch in the Java language, motivated by the desire to support pattern matching.
0 kommentar(er)
