Pattern Matching for switch

JEP 441: Pattern Matching for switch

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

目标

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

■ 在需要时，允许放松 switch 对 null 的历史敌意（即允许更灵活地处理 null 值）。

■ 通过要求模式匹配的 switch 语句覆盖所有可能的输入值，提高 switch 语句的安全性。

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

现状

在 Java 16 中，JEP 394 扩展了 instanceof 操作符，使其可以接受类型模式并执行模式匹配。这一适度的扩展简化了常见的 instanceof-and-cast（即先检查类型再强制转换）惯用法，使其更加简洁且不易出错：

在新代码中，如果运行时 obj 的值是 String 类型的实例，那么 obj 就会匹配类型模式 String s。如果模式匹配成功，则 instanceof 表达式为 true，并且模式变量 s 会被初始化为 obj 强制转换为 String 后的值，然后可以在包含的代码块中使用。

经常需要将一个变量（例如 obj）与多个选项进行比较。Java 支持通过 switch 语句进行多路比较，并且自 Java 14 起支持 switch 表达式（JEP 361）。然而，不幸的是，switch 的功能非常有限。只能对少数类型的值进行 switch——包括整数基本类型（不包括 long）、它们对应的包装类、枚举类型和 String——而且只能测试是否与常量完全相等。

可能希望使用模式来测试同一个变量的多种可能性，并针对每种情况采取特定的操作。但由于现有的 switch 不支持这一点，最终我们不得不编写一连串的 if...else 测试，例如：

这段代码虽然受益于使用了模式匹配的 instanceof 表达式，但远非完美。首先，也是最重要的，这种方法允许编码错误隐藏起来，因为我们使用了一个过于通用的控制结构。在每个 if...else 分支中为 formatted 赋值，但没有任何机制可以让编译器识别并强制执行这一不变性。如果某个“then”块——也许是一个很少执行的分支——没有为 formatted 赋值，就会导致一个 bug。（将 formatted 声明为一个空白局部变量至少可以让编译器的确定性赋值分析发挥作用，但开发者并不总是这样写代码。）

此外，上述代码无法优化；即使底层问题通常是 O(1) 时间复杂度，但在没有编译器优化的情况下，它的时间复杂度仍然是 O(n)。

但是，switch 是模式匹配的完美选择！如果扩展 switch 语句和表达式以支持任何类型，并允许 case 标签使用模式而不是仅仅使用常量，那么可以更清晰、更可靠地重写上述代码：

这个 switch 的语义非常清晰：如果选择器表达式 obj 的值匹配 case 标签中的模式，则该 case 标签适用。（为了简洁起见，我们展示了 switch 表达式，但也可以展示 switch 语句；switch 块，包括 case 标签，都保持不变。）

这段代码的意图更加清晰，因为使用了正确的控制结构：“参数 obj 最多只匹配以下条件之一，找出匹配的条件并评估相应的分支。”作为额外的好处，它更容易优化；在这种情况下，更有可能以 O(1) 的时间复杂度完成分派。

switch 和 null

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

当 switch 仅支持少数引用类型时，这种行为是合理的。然而，如果 switch 允许任何引用类型的表达式作为选择器，并且 case 标签可以包含类型模式，那么单独的 null 测试就显得像是一个不必要的区分，这不仅引入了冗余代码，还增加了出错的可能性。更好的方法是通过允许一个新的 case null 标签将 null 测试直接整合到 switch 中：

当选择器表达式的值为 null 时，switch 的行为始终由其 case 标签决定。如果存在 case null，则 switch 执行与该标签关联的代码；如果没有 case null，则 switch 会像以前一样抛出 NullPointerException。（为了向后兼容当前 switch 的语义，default 标签不会匹配 null 选择器。）

case 细化

与使用常量的 `case` 标签不同，模式 `case` 标签可以适用于多个值。这通常会导致在 `switch` 规则右侧出现条件代码。例如，考虑以下代码：

这里的问题是，使用单一模式来区分情况的方式无法扩展到多个条件。更希望编写多个模式，但需要某种方式来表达对模式的细化。因此，我们在 `switch` 块中允许使用 `when` 子句来为模式 `case` 标签指定保护条件（guard），例如：`case String s when s.equalsIgnoreCase("YES")`。将这种带有保护条件的 `case` 标签称为**带保护的 `case` 标签**，并将布尔表达式称为**保护条件**。

通过这种方式，可以使用保护条件重写上述代码：

这导致了一种更具可读性的 `switch` 编程风格，其中测试的复杂性出现在 `switch` 规则的左侧，而满足测试后执行的逻辑则在规则的右侧。

可以通过为其他已知的常量字符串添加额外规则来进一步增强此示例：

这些示例展示了常量 `case`、模式 `case` 和 `null` 标签如何结合在一起，展示 `switch` 编程的新能力：可以将以前混杂在业务逻辑中的复杂条件逻辑简化为一个可读的、顺序排列的 `switch` 标签列表，并将业务逻辑放在 `switch` 规则的右侧。

switch 和枚举常量

目前，枚举常量在 case 标签中的使用受到高度限制：switch 的选择器表达式必须是枚举类型，并且标签必须是枚举常量的简单名称。例如：

即使在添加模式标签后，这种限制仍然会导致代码过于冗长。例如：

如果可以为每个枚举常量单独设置一个 case，而不是使用大量带保护条件的模式，这段代码会更具可读性。因此，放宽了选择器表达式必须是枚举类型的限制，并允许 case 常量使用枚举常量的限定名称。这使得上述代码可以重写为：

现在，可以为每个枚举常量直接编写 case，而无需使用带保护条件的类型模式，后者之前只是用来绕过类型系统的现有限制。

小结

通过以下四种方式增强了 switch 语句和表达式：

1. 改进枚举常量的 case 标签

支持使用枚举常量的限定名称（如 Suit.CLUBS），从而简化代码并提高可读性。

1. 扩展 case 标签以支持模式和 null

除了常量外，case 标签现在还可以包含模式和 null，从而增强了表达能力。

1. 扩大选择器表达式的类型范围

允许 switch 语句和表达式的选择器表达式使用更广泛的类型，同时引入了对 switch 块穷尽性分析的更丰富支持。

1. 允许 case 标签后跟可选的 when 子句

引入了 when 保护条件，用于进一步细化模式匹配逻辑。

1. 这些增强功能使 switch 更加灵活、简洁和安全，适用于更多场景，尤其是复杂的数据驱动查询和模式匹配需求。

引用：

https://openjdk.org/jeps/441