作者：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。
Case 模式
我们对 case 模式中是否禁止使用 var 绑定进行了额外的讨论，即 case .Foo(var x)：
- 核心小组同意该情形是一个普遍存在的混淆点，尤其因为 Swift 不提供在枚举中获得的绑定值（译者注：本质上获取到的是一个可变的副本）。
- 也就是说，这样的特例会使得 Swift 缺乏统一性。
结论：
- 核心小组决定保留这里的
var。 - 我们将修改编译器，不再提示「将 let 改为 var 让绑定值可变」。
消除注解允许用户充分高效地在 Swift 中继续使用这一模式，但只是人为地将 fixit 按钮静音，编译器不会得到意外的行为。
-- Swift 核心小组
最后总结一下，var 将从参数列表中移除，因为他会使开发者与 inout （注释 1）混淆起来，但是在其他大部分使用 cases 下还是保留 var。同时使用 var 绑定比使用 let 绑定更加简洁。
今天早晨，世界各地的 Swift 开发者都在庆祝。让我们为 Swift Team 深思熟虑地重新审议举杯致敬。
注释 1：我提议了进一步简化 inout ，具体实现是将其从 label 一侧移动到类型声明这一侧，请继续关注，拭目以待。
本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 http://swift.gg。