switch语句表达式
去年12月下旬，我发布了“ Java会使用Switch Expressions吗？ 从那时起，进行了广泛的讨论，表达了不同意见，现在关于Java开关表达式的未来，人们达成了共识。 在12月的博客文章中，我试图捕捉与开关表达式相关的一些主要发展。 但是，我觉得这周琥珀色观察者邮件列表上的Brian Goetz消息标题“ [switch] switch的进一步统一”保证了有关Java switch表达式的新博客文章。
格茨(Goetz)在提醒自己结束游戏不是Java转换表达式时开启了自己的信息。 相反，Goetz指出：“开关表达式应该只是实现真实目标的无可争议的起点，它是一种更具表现力和灵活性的开关构造，可在更广泛的情况下工作，包括支持模式，并且没有敌意设为null，用作表达式或语句等。”
格茨还指出，“转换的确带来了很多负担”，他指出，“这种负担在讨论中产生了可预见的干扰。” 格茨指出：“最糟糕的结果是……发明一种与开关相似但不完全相同的新结构……而不能100％替代当今的古怪开关。” 考虑到这种担忧，最初提出的开关表达式语法被丢弃了，因为它使讨论朝着“最糟糕的可能结果”迈进。
新的交换机统一建议(称为“ Unification Attempt＃2” [UA2])建议“ _all_交换机可以支持旧样式(冒号)或新样式(箭头)大小写标签，但必须坚持一种情况给定开关中的标签。” 这意味着给定switch的case标签都必须使用我们今天在switch语句中使用的“冒号”语法或新提议的“ arrow”语法，但不能在同一switch同时使用。
开发人员可能会选择一种形式而不是另一种形式(“冒号”还是“箭头”)，这是有原因的。 Goetz强调了与switch的当前建议相关联的“箭头”语法的一些优点：“以全箭头的形式，人们讨厌开关的所有东西-需要说出中断，失败的风险以及可疑的作用域-所有走开。”
Goetz在本文中介绍了各种“开关形式”的“结构属性”如何驱动“控制流和作用域规则”。 如下表所示。
| 声明(“交换机的非本地控制流_out_ [继续到封闭循环，使用标签中断，返回]”) | 表达(总计：返回一个值) | |
|---|---|---|
| 结肠(启用穿透) | switch我们知道和“爱”，但增强了 | break返回的值类似于return |
| 箭头(防止掉线) | 语句/冒号的“语法简写”(上)以及
| 箭头( -> )指向返回值 |
Goetz用语句“冒号形式给您旧的控制流，而箭头形式给您新的控制”总结了上表显示的内容。 并且可以用作语句或表达式。 没有人会因混搭而感到困惑。” 他还专门在上表的左下角描述了结构(带有“ arrow”语法的switch语句)：“ Switch语句现在具有更简单的(箭头)形式，其中没有失败，没有奇怪的作用域并且没有大多数时候需要说休息。 可以用这种方式重写许多开关，甚至可以先教这种形式。”
Goetz的总结总结了他的文章：
结果是一个具有现代和传统风味的开关构造，它支持表达式或语句。 您可以立即查看开关的中间，并告诉(通过箭头还是冒号)它是否具有旧的控制流。
迄今为止，对拟议的“统一尝试＃2”的总体React是压倒性的，但并非没有预期的持续担忧。 加文·比尔曼(Gavin Bierman)总结了这一建议，他说：“这实际上是与增强而不是新结构有关的所有内容”，并指出：“在撰写本文时编写修订的规范–准备好！”
switch语句表达式
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
