跳到主要内容

JEP 406：switch 模式匹配（预览版）

QWen Max 中英对照 JEP 406: Pattern Matching for switch (Preview)

总结​

通过为 switch 表达式和语句添加模式匹配，以及对模式语言的扩展来增强 Java 编程语言。将模式匹配扩展到 switch 可以使一个表达式根据多个模式进行测试，每个模式都有特定的操作，从而能够简洁且安全地表达以数据为导向的复杂查询。这是 JDK 17 中的一个 预览语言功能。

目标​

  • 通过允许在 case 标签中出现模式，扩展 switch 表达式和语句的表现力与适用性。

  • 在需要时，允许放松 switch 历史上对空值的严格限制。

  • 引入两种新模式：受保护模式（guarded patterns），允许使用任意布尔表达式细化模式匹配逻辑；以及带括号模式（parenthesized patterns），用于解决某些解析歧义问题。

  • 确保所有现有的 switch 表达式和语句无需修改即可继续编译，并以相同的语义执行。

  • 不引入与传统 switch 结构分离的、具有模式匹配语义的新的类似 switch 的表达式或语句。

  • 当 case 标签为模式时，不改变 switch 表达式或语句的行为，与 case 标签为传统常量时保持一致。

动机​

在 Java 16 中，JEP 394 对 instanceof 运算符进行了扩展，使其能够接受一个 类型模式 并执行 模式匹配。这一适度的扩展简化了熟悉的 instanceof-然后-强制转换的习惯用法：

// Old code
if (o instanceof String) {
    String s = (String)o;
    ... use s ...
}

// New code
if (o instanceof String s) {
    ... use s ...
}
java

我们经常需要将 o 等变量与多个选项进行比较。Java 通过 switch 语句支持多路比较，并且从 Java 14 开始支持 switch 表达式（JEP 361），但遗憾的是，switch 的功能非常有限。你只能对少数几种类型的值进行切换 —— 数字类型、枚举类型和 String 类型 —— 并且只能测试与常量的完全相等性。我们可能希望使用模式来针对多种可能性测试同一个变量，并在每种情况下采取特定的操作，但由于现有的 switch 不支持这一点，最终我们不得不编写一连串的 if...else 测试，例如：

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}
java

这段代码受益于使用模式 instanceof 表达式，但远非完美。首先，这种方法允许编码错误隐藏起来，因为我们使用了一个过于通用的控制结构。我们的意图是在 if...else 链的每个分支中为 formatted 赋值，但没有任何机制能够让编译器识别并验证这一不变量。如果某些块（可能是很少执行的块）没有对 formatted 进行赋值，就会产生一个 bug。（将 formatted 声明为一个空白局部变量至少可以让编译器的确定性赋值分析参与进来，但这样的声明并不总是会被写出来。）此外，上述代码无法优化；即使底层问题通常是 O(1) 的复杂度，但在缺乏编译器优化的情况下，它的时间复杂度会是 O(n)。

但是 switch 非常适合用于模式匹配！如果我们将 switch 语句和表达式扩展到适用于任何类型，并允许 case 标签使用模式而不仅仅是常量，那么我们可以更清晰、更可靠地重写上面的代码：

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}
java

这个 switch 的语义很明确：如果选择器表达式 o 的值与模式匹配，那么带有该模式的 case 标签就会匹配该值。（为了简洁起见，我们展示了一个 switch 表达式，但也可以展示一个 switch 语句；包括 case 标签在内的 switch 块保持不变。）

这段代码的意图更清晰，因为我们使用了正确的控制结构：我们说的是，“参数 o 最多匹配下列条件之一，找出它并计算相应分支。” 作为奖励，它是可优化的；在这种情况下，我们更有可能以 O(1) 的时间执行调度。

模式匹配与 null​

传统上，如果选择器表达式的结果为 null，switch 语句和表达式会抛出 NullPointerException，因此必须在 switch 外部进行 null 值检测：

static void testFooBar(String s) {
    if (s == null) {
        System.out.println("oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}
java

当 switch 仅支持少数引用类型时，这是合理的。然而，如果 switch 允许选择器表达式为任意类型，并且 case 标签可以具有类型模式，那么单独的 null 检查感觉就像是一种武断的区别，还会引发不必要的模板代码和出错机会。最好将 null 检查集成到 switch 中：

static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}
java

当选择器表达式的值为 null 时，switch 的行为始终由其 case 标签决定。如果有 case null（或全类型模式；见下面的 4a），switch 将执行与该标签关联的代码；如果没有 case null，switch 将抛出 NullPointerException，与之前相同。（为了与当前 switch 的语义保持向后兼容，default 标签不会匹配 null 选择器。）

我们可能希望以与另一个 case 标签相同的方式来处理 null。例如，在以下代码中，case null, String s 将匹配 null 值以及所有的 String 值：

static void testStringOrNull(Object o) {
    switch (o) {
        case null, String s -> System.out.println("String: " + s);
    }
}
java

在 switch 中优化模式​

在 switch 中尝试使用模式时，通常需要对模式进行细化。考虑以下针对 Shape 值进行切换的代码：

class Shape {}
class Rectangle extends Shape {}
class Triangle  extends Shape { int calculateArea() { ... } }

static void testTriangle(Shape s) {
    switch (s) {
        case null:
            break;
        case Triangle t:
            if (t.calculateArea() > 100) {
                System.out.println("Large triangle");
                break;
            }
        default:
            System.out.println("A shape, possibly a small triangle");
    }
}
java

这段代码的意图是为大三角形（面积超过 100）提供一个特殊处理逻辑，并为其他所有情况（包括小三角形）提供默认处理逻辑。然而，我们无法用单一模式直接表达这一点。首先，我们必须编写一个匹配所有三角形的 case 标签，然后将对三角形面积的测试放置在对应的语句组中（显得有些不太直观）。接着，当三角形面积小于 100 时，我们需要利用贯穿（fall-through）来获得正确的行为。（注意 break; 在 if 块中的精心放置位置。）

这里的问题在于，使用单一模式来区分不同情况无法扩展到单一条件之外。我们需要某种方式来表达对模式的细化。一种方法可能是允许 case 标签被细化；这种细化在其他编程语言中被称为保护条件（guard）。例如，我们可以引入一个新的关键字 where，让它出现在 case 标签的末尾，并在其后跟随一个布尔表达式，例如：case Triangle t where t.calculateArea() > 100。

然而，还有一种更具表现力的方法。我们不必扩展 case 标签的功能，而是可以扩展模式本身的语言。我们可以添加一种新的模式，称为受保护模式（guarded pattern），写作 p && b，它允许通过任意布尔表达式 b 来细化模式 p。

通过这种方法，我们可以重新审视 testTriangle 代码，以直接表达大三角形的特殊情况。这样就消除了在 switch 语句中使用贯穿（fall-through），从而意味着我们可以享受简洁的箭头风格（->）规则：

static void testTriangle(Shape s) {
    switch (s) {
        case Triangle t && (t.calculateArea() > 100) ->
            System.out.println("Large triangle");
        default ->
            System.out.println("A shape, possibly a small triangle");
    }
}
java

如果 s 的值首先匹配类型模式 Triangle t，并且表达式 t.calculateArea() > 100 的计算结果为 true，那么它就符合模式 Triangle t && (t.calculateArea() > 100)。

使用 switch 可以在应用程序需求发生变化时轻松理解和更改 case 标签。例如，我们可能希望将三角形从默认路径中分离出来；这可以通过同时使用细化模式和非细化模式来实现：

static void testTriangle(Shape s) {
    switch (s) {
        case Triangle t && (t.calculateArea() > 100) ->
            System.out.println("Large triangle");
        case Triangle t ->
            System.out.println("Small triangle");
        default ->
            System.out.println("Non-triangle");
    }
}
java

描述​

我们通过两种方式增强了 switch 语句和表达式：

  • 扩展 case 标签以包含模式而不仅仅是常量，并且

  • 引入两种新的模式：受保护的模式 和 带括号的模式。

switch 标签中的模式​

该提案的核心是引入一个新的 case p switch 标签，其中 p 是一个模式。然而，switch 的本质保持不变：选择器表达式的值会与 switch 标签进行比较，其中一个标签被选中，并执行与该标签关联的代码。区别在于，现在对于带有模式的 case 标签，选择是通过模式匹配而不是相等性检查来确定的。例如，在以下代码中，o 的值与模式 Long l 匹配，并且与 case Long l 关联的代码将被执行：

Object o = 123L;
String formatted = switch (o) {
    case Integer i -> String.format("int %d", i);
    case Long l    -> String.format("long %d", l);
    case Double d  -> String.format("double %f", d);
    case String s  -> String.format("String %s", s);
    default        -> o.toString();
};
java

当 case 标签可以包含模式时，存在四个主要设计问题：

  1. 增强的类型检查
  2. switch 表达式和语句的完整性
  3. 模式变量声明的作用域
  4. 处理 null

1. 增强的类型检查​

1a. 选择器表达式类型​

在 switch 中支持模式匹配意味着我们可以放宽当前对选择器表达式类型的限制。目前，普通 switch 的选择器表达式的类型必须是以下之一：整数基本类型（char、byte、short 或 int）、相应的包装类形式（Character、Byte、Short 或 Integer）、String 或枚举类型。我们对此进行了扩展，现在要求选择器表达式的类型可以是整数基本类型或任何引用类型。

例如，在以下模式 switch 中，选择器表达式 o 会与涉及类类型、枚举类型、记录类型和数组类型（以及一个 null 的 case 标签和一个 default）的类型模式进行匹配：

record Point(int i, int j) {}
enum Color { RED, GREEN, BLUE; }

static void typeTester(Object o) {
    switch (o) {
        case null     -> System.out.println("null");
        case String s -> System.out.println("String");
        case Color c  -> System.out.println("Color with " + Color.values().length + " values");
        case Point p  -> System.out.println("Record class: " + p.toString());
        case int[] ia -> System.out.println("Array of ints of length" + ia.length);
        default       -> System.out.println("Something else");
    }
}
java

switch 块中的每个 case 标签必须与选择器表达式兼容。对于带有模式的 case 标签（称为 模式标签），我们使用现有的 表达式与模式的兼容性 概念 (JLS §14.30.1)。

1b. 模式标签的主导性​

选择器表达式有可能在 switch 块中匹配多个标签。考虑以下有问题的示例：

static void error(Object o) {
    switch(o) {
        case CharSequence cs ->
            System.out.println("A sequence of length " + cs.length());
        case String s ->    // Error - pattern is dominated by previous pattern
            System.out.println("A string: " + s);
        default -> {
            break;
        }
    }
}
java

第一个模式标签 case CharSequence cs 主导 了第二个模式标签 case String s，因为每个匹配模式 String s 的值同样也匹配模式 CharSequence cs，但反之则不成立。这是由于第二个模式的类型 String 是第一个模式类型 CharSequence 的子类型。

形如 case p 的模式标签中，如果 p 是选择器表达式的类型的全模式，则它主导标签 case null。这是因为全模式匹配所有值，包括 null。

形式为 case p 的模式标签主导了形式为 case p && e 的模式标签，即，其中的模式是原始模式的受保护版本。例如，模式标签 case String s 主导了模式标签 case String s && s.length() > 0，因为每个匹配受保护模式 String s && s.length() > 0 的值同样也匹配模式 String s。

编译器会检查所有的模式标签。如果 switch 块中的某个模式标签被该 switch 块中较早的模式标签所支配，则会产生编译时错误。

这一主导要求确保了如果一个 switch 块仅包含类型模式的 case 标签，这些标签将按照子类型顺序出现。

主导性的概念类似于 try 语句中对 catch 子句的条件要求，即如果捕获异常类 E 的 catch 子句前面存在一个能够捕获 E 或 E 的超类的 catch 子句，则会导致错误（JLS §11.2.3）。从逻辑上讲，前面的 catch 子句主导了后续的 catch 子句。

如果一个 switch 块中存在多个匹配所有情况的 switch 标签，同样会导致编译时错误。两个 匹配所有 的标签分别是 default 和全类型模式（详见下面的 4a）。

2. switch 表达式和语句中模式标签的完整性​

switch 表达式要求在 switch 块中处理选择器表达式的所有可能值。这保证了 switch 表达式成功求值后总会产生一个值的特性。对于普通的 switch 表达式，这是通过在 switch 块上施加一组相当直接的额外条件来强制执行的。对于模式 switch 表达式，我们定义了一个关于 switch 块的 类型覆盖 的概念。

考虑以下（错误的）模式 switch 表达式：

static int coverage(Object o) {
    return switch (o) {         // Error - incomplete
        case String s -> s.length();
    };
}
java

该 switch 块只有一个 case 标签，即 case String s。这会匹配选择器表达式中类型为 String 子类型的所有值。因此，我们说此箭头规则的类型覆盖范围是 String 的每个子类型。此模式 switch 表达式并不完整，因为其 switch 块的类型覆盖范围不包括选择器表达式的类型。

请看这个（仍然有错误的）例子：

static int coverage(Object o) {
    return switch (o) {         // Error - incomplete
        case String s  -> s.length();
        case Integer i -> i;
    };
}
java

此 switch 块的类型覆盖范围是其两条箭头规则覆盖范围的并集。换句话说，类型覆盖范围是 String 的所有子类型和 Integer 的所有子类型的集合。但是，类型覆盖范围仍然不包括选择器表达式的类型，因此此模式 switch 表达式也是不完整的，并会导致编译时错误。

default 的类型覆盖了所有类型，所以这个例子（终于！）是合法的：

static int coverage(Object o) {
    return switch (o) {
        case String s  -> s.length();
        case Integer i -> i;
        default -> 0;
    };
}
java

如果选择器表达式的类型是一个密封类（JEP 409），那么类型覆盖率检查可以考虑密封类的 permits 子句，以确定 switch 块是否完整。请看以下示例，其中有一个 sealed 接口 S，它允许三个子类 A、B 和 C：

sealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}  // Implicitly final

static int testSealedCoverage(S s) {
    return switch (s) {
        case A a -> 1;
        case B b -> 2;
        case C c -> 3;
    };
}
java

编译器可以确定 switch 块的类型覆盖范围为 A、B 和 C。由于选择器表达式的类型 S 是一个密封接口，其允许的子类正好是 A、B 和 C，因此这个 switch 块是完整的。结果就是，不需要 default 标签。

为了防止不兼容的独立编译，编译器会自动添加一个 default 标签，其代码会抛出 IncompatibleClassChangeError 异常。仅当 sealed 接口被修改且 switch 代码未重新编译时，才会执行到该标签。实际上，编译器在为你强化代码。

对于模式 switch 表达式的要求是必须完整的，这类似于处理选择器表达式为枚举类的 switch 表达式的情况。如果枚举类的每个常量都有对应的分支，则不需要 default 标签。

让编译器验证 switch 表达式 的完整性是非常有用的。我们不仅将此检查保留给 switch 表达式，还将其扩展到 switch 语句中。出于向后兼容的原因，所有现有的 switch 语句将继续保持不变并正常编译。但如果某个 switch 语句使用了本 JEP 中详述的任何新特性，那么编译器将会检查其是否完整。

更准确地说，如果 switch 语句使用了模式或 null 标签，或者其选择器表达式不是以下遗留类型之一（char、byte、short、int、Character、Byte、Short、Integer、String 或枚举类型），则要求其具有完整性。

这意味着现在 switch 表达式和switch 语句都可以从更严格的类型检查中受益。例如：

sealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}  // Implicitly final

static void switchStatementComplete(S s) {
    switch (s) {    // Error - incomplete; missing clause for permitted class B!
        case A a :
            System.out.println("A");
            break;
        case C c :
            System.out.println("B");
            break;
    };
}
java

使大多数 switch 语句完整只需在 switch 主体末尾添加一个简单的 default 子句即可。这会使代码更加清晰且易于验证。例如，以下 switch 语句并不完整且存在错误：

Object o = ...
switch (o) {    // Error - incomplete!
    case String s:
        System.out.println(s);
        break;
    case Integer i:
        System.out.println("Integer");
        break;
}
java

它可以被简单地补全：

Object o = ...
switch (o) {    
    case String s:
        System.out.println(s);
        break;
    case Integer i:
        System.out.println("Integer");
        break;
    default:    // Now complete!
        break;
}
java

未来 Java 语言的编译器可能会对不完整的传统 switch 语句发出警告。

3. 模式变量声明的范围​

模式变量（JEP 394）是由模式声明的局部变量。模式变量声明的特殊之处在于其作用域是流敏感型的。以下面的例子回顾一下，其中类型模式 String s 声明了模式变量 s：

static void test(Object o) {
    if ((o instanceof String s) && s.length() > 3) {
        System.out.println(s);
    } else {
        System.out.println("Not a string");
    }
}
java

s 的声明在 && 表达式的右侧操作数以及“then”块中是有效的。然而，它在“else”块中无效；为了使控制流转移到“else”块，模式匹配必须失败，在这种情况下，模式变量将不会被初始化。

我们将这种对模式变量声明的流敏感作用域概念扩展到包含 case 标签中出现的模式声明，并引入两条新规则：

  1. 在 switch 规则的 case 标签中出现的模式变量声明的作用域包括出现在箭头右侧的表达式、代码块或 throw 语句。

  2. 在 switch 带标签的语句组的 case 标签中出现的模式变量声明的作用域（其后没有更多的 switch 标签）包含该语句组的代码块语句。

这个示例展示了第一条规则的实际应用：

static void test(Object o) {
    switch (o) {
        case Character c -> {
            if (c.charValue() == 7) {
                System.out.println("Ding!");
            }
            System.out.println("Character");
        }
        case Integer i ->
            throw new IllegalStateException("Invalid Integer argument of value " + i.intValue());
        default -> {
            break;
        }
    }
}
java

模式变量 c 的声明范围是第一个箭头右侧的块。

模式变量 i 的声明范围是第二个箭头右侧的 throw 语句。

第二条规则更为复杂。让我们先来看一个例子，其中只有一个 case 标签对应一个 switch 标记语句组：

static void test(Object o) {
    switch (o) {
        case Character c:
            if (c.charValue() == 7) {
                System.out.print("Ding ");
            }
            if (c.charValue() == 9) {
                System.out.print("Tab ");
            }
            System.out.println("character");
        default:
            System.out.println();
    }
}
java

模式变量 c 的声明范围包括语句组中的所有语句，即两个 if 语句和 println 语句。该范围不包括 default 语句组中的语句，即使第一个语句组的执行可以贯穿 default 开关标签并执行这些语句。

通过声明模式变量的 case 标签跌落的可能性必须作为编译时错误排除。考虑以下错误示例：

static void test(Object o) {
    switch (o) {
        case Character c:
            if (c.charValue() == 7) {
                System.out.print("Ding ");
            }
            if (c.charValue() == 9) {
                System.out.print("Tab ");
            }
            System.out.println("character");
        case Integer i:                 // Compile-time error
            System.out.println("An integer " + i);
        default:
            break;
    }
}
java

如果允许这样做，并且选择器表达式 o 的值为 Character，那么在执行 switch 块时可能会跳过第二个语句组（在 case Integer i: 之后），此时模式变量 i 将未被初始化。因此，允许执行跳过声明了模式变量的 case 标签属于编译时错误。

这就是为什么不允许 case Character c: case Integer i: ...。类似的推理也适用于禁止在 case 标签中使用多个模式：无论是 case Character c, Integer i: ... 还是 case Character c, Integer i -> ... 都不被允许。如果允许这样的 case 标签，那么在冒号或箭头之后，c 和 i 都会处于作用域中，但根据 o 的值是 Character 还是 Integer，只有 c 或 i 中的一个会被初始化。

另一方面，如本例所示，跳过未声明模式变量的标签是安全的：

void test(Object o) {
    switch (o) {
        case String s:
            System.out.println("A string");
        default:
            System.out.println("Done");
    }
}
java

4. 处理 null​

4a. 匹配 null​

传统上，如果选择器表达式的结果为 null，switch 会抛出 NullPointerException。这是一种广为人知的行为，我们并不建议对任何现有的 switch 代码进行更改。

然而，鉴于模式匹配和 null 值存在合理且无异常的语义，这提供了一个机会，可以在保持与现有 switch 语义兼容的同时，使模式 switch 对 null 更加友好。

首先，我们为 case 引入一个新的 null 标签，当选择器表达式的值为 null 时，它会明确匹配。

其次，我们观察到，如果一个模式在选择器表达式的类型上是完全的，并且出现在模式 case 标签中，那么当选择器表达式的值为 null 时，该标签也会匹配。

如果类型 T 是类型 U 的子类型，则类型为 U 的类型模式 p 对于类型 T 是完全的。例如，类型模式 Object o 对于类型 String 是完全的。

我们取消了当选择器表达式的值为 null 时，switch 语句立即抛出 NullPointerException 的通用规则。相反，我们会检查 case 标签以确定 switch 的行为：

  • 如果选择器表达式计算结果为 null，则任何 null 的 case 标签或全模式的 case 标签被视为匹配。如果 switch 块中没有与此类标签关联，则 switch 会抛出 NullPointerException，与之前相同。

  • 如果选择器表达式计算结果为非 null 值，则正常选择匹配的 case 标签。如果没有 case 标签匹配，则任何匹配所有情况的标签将被视为匹配。

例如，对于下面的声明，求值 test(null) 会打印 null! 而不是抛出 NullPointerException：

static void test(Object o) {
    switch (o) {
        case null     -> System.out.println("null!");
        case String s -> System.out.println("String");
        default       -> System.out.println("Something else");
    }
}
java

这种围绕 null 的新行为就好像编译器自动丰富了 switch 块，为其添加了一个抛出 NullPointerException 的 case null。换句话说，这段代码：

static void test(Object o) {
    switch (o) {
        case String s  -> System.out.println("String: " + s);
        case Integer i -> System.out.println("Integer");
        default  -> System.out.println("default");
    }
}
java

等价于：

static void test(Object o) {
    switch (o) {
        case null      -> throw new NullPointerException();
        case String s  -> System.out.println("String: "+s);
        case Integer i -> System.out.println("Integer");
        default  -> System.out.println("default");
    }
}
java

在这两个示例中，评估 test(null) 都将导致抛出 NullPointerException。

我们保留了现有 switch 语句的直观性，即对 null 执行 switch 操作是一种异常情况。在模式匹配的 switch 中的区别在于，你有一个机制可以直接在 switch 内部处理这种情况，而不是在外部处理。如果你选择不在 switch 块中包含匹配 null 的 case 标签，那么对 null 值进行 switch 操作时将像以前一样抛出 NullPointerException。

4b. 由 null 标签引起的新标签形式​

JDK 16 中的 switch 块支持两种风格：一种基于带标签的语句组（: 形式），在这种形式中可以实现贯穿；另一种基于单结果形式（-> 形式），在这种形式中无法实现贯穿。在前一种风格中，多个标签通常写作 case l1: case l2:，而在后一种风格中，多个标签写作 case l1, l2:。

支持 null 标签意味着可以在 : 形式中表达一些特殊情况。例如：

Object o = ...
switch(o) {
    case null: case String s: 
        System.out.println("String, including null");
        break;
    ...
}
java

人们期望 : 和 -> 具有相同的表达能力，并且如果前者支持 case A: case B: 的写法，那么后者也应该支持 case A, B -> 的写法。因此，前面的例子表明我们应该支持 case null, String s -> 标签，如下所示：

Object o = ...
switch(o) {
    case null, String s -> System.out.println("String, including null");
    ...
}
java

当 o 为 null 引用或者它是一个 String 时，o 的值与这个标签匹配。在这两种情况下，模式变量 s 都会使用 o 的值进行初始化。

（反过来的形式，case String s, null 也应该被允许并且表现一致。）

将 null 情况与 default 标签结合使用也是有意义的（并且并不少见），即：

Object o = ...
switch(o) {
    ...
    case null: default: 
        System.out.println("The rest (including null)");
}
java

同样，这应该在 -> 形式中得到支持。为此，我们引入了一个新的 default 情况标签：

Object o = ...
switch(o) {
    ...
    case null, default -> 
        System.out.println("The rest (including null)");
}
java

如果 o 的值是空引用值，或者没有其他标签匹配，那么它与该标签匹配。

带保护的和带括号的模式​

成功匹配模式后，我们通常会进一步测试匹配结果。这可能会导致代码变得繁琐，例如：

static void test(Object o) {
    switch (o) {
        case String s:
            if (s.length() == 1) { ... }
            else { ... }
            break;
        ...
    }
}
java

期望的测试 —— 即 o 是一个长度为 1 的 String —— 不幸地被分散在 case 标签和随后的 if 语句之间。如果模式 switch 支持在 case 标签中组合模式和布尔表达式，我们就可以提高可读性。

我们并没有添加另一个特殊的 case 标签，而是通过引入受保护的模式来增强模式语言，其写法为 p && e。这使得上面的代码可以重写，从而将所有条件逻辑都提升到 case 标签中：

static void test(Object o) {
    switch (o) {
        case String s && (s.length() == 1) -> ...
        case String s                      -> ...
        ...
    }
}
java

如果 o 同时是 String 且长度为 1，则匹配第一种情况。如果 o 是具有其他长度的 String，则匹配第二种情况。

有时，我们需要为模式添加括号以避免解析歧义。因此，我们扩展了模式的语言以支持写为 (p) 的带括号模式，其中 p 是一个模式。

更确切地说，我们改变了模式的语法。假设添加了 JEP 405 的记录模式和数组模式，模式的语法将变为：

Pattern:
  PrimaryPattern
  GuardedPattern

GuardedPattern:
  PrimaryPattern && ConditionalAndExpression

PrimaryPattern:
  TypePattern
  RecordPattern
  ArrayPattern
  ( Pattern )
java

一个受保护的模式的形式为 p && e，其中 p 是一个模式，e 是一个布尔表达式。在受保护的模式中，任何在子表达式中使用但未声明的局部变量、形式参数或异常参数必须是 final 或实际上是 final 的。

受保护的模式 p && e 引入了模式 p 和表达式 e 所引入的模式变量的并集。p 中任何模式变量声明的作用域都包括表达式 e。这允许使用诸如 String s && (s.length() > 1) 这样的模式，该模式匹配一个可以转换为 String 的值，且该字符串的长度大于一。

如果一个值首先匹配模式 p，其次表达式 e 的计算结果为 true，那么该值就匹配受保护的模式 p && e。如果该值不匹配 p，则不会尝试计算表达式 e。

带括号的模式 形如 (p)，其中 p 是一个模式。带括号的模式 (p) 引入了由子模式 p 引入的模式变量。如果一个值匹配模式 p，则它也匹配带括号的模式 (p)。

我们还更改了 instanceof 表达式的语法为：

InstanceofExpression:
  RelationalExpression instanceof ReferenceType
  RelationalExpression instanceof PrimaryPattern
java

这一改动，以及受保护模式的语法规则中的非终结符 ConditionalAndExpression，确保了例如表达式 e instanceof String s && s.length() > 1 仍然可以明确无误地解析为表达式 (e instanceof String s) && (s.length() > 1)。如果末尾的 && 意在成为受保护模式的一部分，则整个模式应当加上括号，例如，e instanceof (String s && s.length() > 1)。

在受保护模式的语法规则中使用非终结符 ConditionalAndExpression 还消除了关于带有受保护模式的 case 标签的另一个潜在歧义。例如：

boolean b = true;
switch (o) {
    case String s && b -> s -> s;
}
java

如果允许受保护模式的保护表达式为任意表达式，那么就会存在一个歧义，即第一个出现的 -> 是属于 lambda 表达式的一部分还是属于 switch 规则（其主体是一个 lambda 表达式）的一部分。由于 lambda 表达式永远不可能是有效的布尔表达式，因此限制保护表达式的语法是安全的。

未来工作​

  • 目前，模式 switch 不支持原始类型 boolean、float 和 double。它们的实用性似乎很小，但可以添加对这些类型的支持。

  • 我们预计，在未来，通用类将能够声明解构模式以指定它们如何被匹配。这样的解构模式可以与模式 switch 一起使用，从而产生非常简洁的代码。例如，如果我们有一个 Expr 的层次结构，其中包含 IntExpr（包含单个 int）、AddExpr 和 MulExpr（包含两个 Expr）以及 NegExpr（包含单个 Expr）的子类型，那么我们可以一步匹配 Expr 并针对特定的子类型进行操作：

    int eval(Expr n) {
         return switch(n) {
             case IntExpr(int i) -> i;
             case NegExpr(Expr n) -> -eval(n);
             case AddExpr(Expr left, Expr right) -> eval(left) + eval(right);
             case MulExpr(Expr left, Expr right) -> eval(left) * eval(right);
             default -> throw new IllegalStateException();
         };
    }
    java

    如果没有这种模式匹配，表达这种特殊的多态计算就需要使用繁琐的[访问者模式][visitor]。模式匹配通常更加透明和直接。

  • 添加 AND 和 OR 模式也可能很有用，这样可以为带有模式的 case 标签提供更多表达能力。

替代方案​

  • 与其支持模式 switch，我们也可以定义一个 类型 switch，它只支持根据选择表达式的类型进行切换。此功能在规范和实现上更简单，但表达能力却差得多。

  • 对于带保护的模式，还有许多其他的语法选项，例如 p where e、p when e、p if e，甚至是 p &&& e。

  • 带保护模式的一种替代方案是直接将 保护条件 支持为一种特殊的 case 标签形式：

    SwitchLabel:
      case Pattern [ when Expression ]
      ...
    java

    在 case 标签中支持保护条件需要引入 when 作为新的上下文关键字，而带保护的模式不需要新的上下文关键字或运算符。带保护的模式提供了更大的灵活性，因为带保护的模式可以出现在其应用的位置附近，而不是在 switch 标签的末尾。

依赖​

此 JEP 建立在 instanceof 的模式匹配（JEP 394）以及 switch 表达式所提供的增强功能（JEP 361）之上。我们希望此 JEP 能够与 JEP 405 同步，后者定义了两种支持嵌套的新模式。该实现可能会利用动态常量（JEP 309）。