切换表达式到Java吗？

已创建一个标题为“ Java语言的开关表达式”的JEP草案。当前的“摘要”状态为：“扩展switch语句，以便可以将其用作语句或表达式，并改善switch处理null的方式。这些将简化日常编码，并为在switch使用模式匹配做好准备。” 除了启用令人兴奋的模式匹配JEP（305）之外，所提议的Java switch表达式本身还具有一些有希望的特征。

Java教程将Java 语句定义为“大致等同于自然语言中的句子”的“执行的完整单元”。它将Java 表达式定义为“由变量，运算符和方法调用组成的构造，其结果为单个值。” 当前的Java switch是一条语句，但是JEP草案建议将switch也作为表达式来支持。

JEP的Switch Expression草案在其“动机”部分指出：“当我们准备增强Java语言以支持模式匹配时，现有的switch语句的一些不规则性（长期以来一直困扰着用户）成为了障碍。” JEP草案具有很高的可读性，并包含有趣的讨论点和说明性的代码示例，这些示例说明了当前如何在其他Java构造函数中经常使用Java switch语句来有效地充当表达式。 JEP草案显示了将switch扩展为用作表达式的提议，以及作为语句得到支持的提议，将如何提高代码的可读性和可维护性。

Java表达式需要“求值为单个值”。当前提出的switch表达式将允许break关键字充当Java方法中的return 。可以在break关键字之后指定一个值，并且该值将从switch表达式中“返回”。

因为Java 表达式 “求值为单个值”，所以必须使用用作表达式的Java switch来提供默认值。 JEP草案中涵盖的一个有趣的转折是枚举。 JEP草案指出：“……对于涵盖所有已知情况的枚举switch表达式（最终，通过密封类型的switch表达式），编译器可以插入默认子句，指示枚举定义在两次编译之间已更改时间和运行时间。（这是开发人员今天手动执行的操作，但是与手工编写的相比，让编译器插入它既不那么具有侵入性，又可能具有更具描述性的错误消息。）“我发现这特别有趣，因为我已经看到很多情况了在这种情况下，开发人员没有为枚举上的switch编写“默认值”，因为当时所有的枚举值都被case s覆盖，或者编写了非常通用的错误消息。实际上，碰到后者的多个示例终于使我写了博客文章“ Log Unexpected Switch Options” 。

JEP草案还涵盖了一些建议的增强功能，这些功能将使当前的switch语句和新的switch表达式都受益。其中之一就是能够指示如何处理传递给switch语句的null引用类型。例如，今天，如果将null String传递给switch语句，则会引发NullPointerException 。通过此建议，开发人员可以指定case null子句。当前的提案将处理任何未明确处理的null因为今天在switch会处理null （通过抛出NullPointerException ）。

针对当前switch语句和拟议的switch表达式提出的第二个有益特征是允许单个case子句支持多个以逗号分隔的潜在匹配值。可以使用单个case而不是使用共享单个break三个case子句指定适用于相同行为的三个值。

“切换表达式草稿”仍然是一个草稿，甚至没有分配编号，因此很容易受到潜在更改的影响。确实，该建议已在邮件列表中进行了讨论，并进行了相当多的修改，例如“ Switch expressions-某些修订版” 。我发现邮件列表中有一条消息“ 切换float / double / long ”特别有趣。这个有趣的消息包含全部或技术和历史细节，包括为何今天的switch语句不能long支持的背景，以及“居民浮点专家” Joe Darcy提供的有关浮点比较的有趣分析。

David Goldberg在1991年发表的文章“ 每位计算机科学家都应了解的浮点算法 ”是了解浮点算术和表示法复杂性的著名资源。达西（Darcy）对这些问题和IEEE 754浮点数提供了一些有趣的见解。他写道：“为了解决对浮点数的一些常见误解，尽管通常建议*不要*比较浮点数是否相等，但是进行此类比较的定义非常明确，但可能并不能满足您的要求。” 达西处理NaN ，正零和负零以及正无穷大和负无穷大的处理。一个有趣的结论是，可以实现允许switch浮点数字类型float来真正打开Float.floatToIntBits（float）提供的值。

如果将Java进行扩展，那么看起来可能会比Java的switch快一些激动人心的时刻，以便除了当前用作语句之外，还可以将其用作表达式。这是一个可以导致代码更干净，出错空间更少的开发。