转载

2016 var-vs-let 的停火协定

作者：Erica Sadun，原文链接，原文日期：2016-01-29

译者： walkingway ；校对： Cee ；定稿：小锅

在 Swift 开源之前，苹果在其语言进化中 SE-0003 将 var 形式的函数参数进行了移除，并且模式匹配将正式出现在 Swift 3.0 中。

自那以后，Swift 社区一遍又一遍地反对这个决定，尤其是那些在 case 模式匹配以及 if/guard/for 语句中使用了 var 的人们。

今天，Swift 团队正式发表了一项声明：

经过核心团队对 SE-0003 的讨论，我们现在有了新的结论。正如其他主题中提到的那样，这个提议有些不同寻常，因为它早于 Swift 开源之前就被提了出来，因此并没有经过充分的演化，也没有开放给公众去评审。

核心小组将这项提案分成几个不同的小案例，每一个都得出了不同的结论。至此我们已经清楚这并不是一个非黑即白的主题，围绕该主题存在很多相左的意见。这里是核心小组给出的结论和一些理由：

参数列表

参数列表中使用 var 有下面几个问题：

参数列表当前已经同时允许使用 inout 和 var ，这会对正在学习 Swift 的初学者产生一些混淆，他们会理所当然地将这里的 var 理解成也提供「引用」的语义。
Swift 中的参数列表并不对应「模式」，也就是说不管 let 也好 var 也罢在那个位置都不具有其真正的意义。参数是模式这种想法曾在 Swift 早期的设计中出现过，但很久之前就移除了，也不会重新考虑了。
参数列表中的 var 看上去异常怪异，是因为它将实现细节强加到了函数接口上。为了公平起见，我们已经有了「API 名（API names）」和「内部名（Internal names）」来处理，但是那是个 var 暴露了更大的语意实现细节。

结论：核心小组最终决定从参数列表中移除 var 和 let 。参数列表中的 var 是一个快捷的语法糖，内部其实是定义了一些微小的样板文件（底层还是拷贝），然而，经过对开销和收益比进行权衡还是不值得保留它。

模式

if var 、 for var 、 if case var 等等都是使用了模式语法（又称为「模式匹配」和 TSPL 中的「解构」特性）（校者注：TSPL，Types and Semantics for Programming Languages）(定稿注：TSPL，编程语言中的类型与语义)。而当我们讨论是否要从参数列表中移出该特性时，得到的意见很不统一：

目前，在 Swift 语言中，let 和 var 关键字具有二元性。这种二元性很常见，能够将两者统一起来，在实际应用中也有很好的表现。从模式匹配中移除 var 将减少语言的统一性，因为模式并不会对齐到 var/let 声明上。
在学习 Swift 的早期你就应该掌握这门语言「值传递」的含义，即 var x = y 总是「值拷贝」的。基于这点再结合上文提到的二元性，人们很有理由会认为 if var x = y 产生一个值拷贝而并不是一个引用绑定。
不管上面怎么说明，还是会有一部人产生混淆，会认为 if var 是执行了一个引用绑定。然而，我们感觉这种更多是来自于时间点的困惑，而不是作为函数签名的一部分暴露出来的 var 。

结论：核心小组决定在模式匹配中保留 var 和 let 。