【51CTO译文】无论结果是好是坏，苹果打造的全新语言都将让我们以自己的方式处理开发工作。
对于任何一位苹果公司之外的关注者而言，Swift语言的突然面世究竟会带来怎样的后续影响都实在难以断言。就在本届WWDC大会的主题演讲中，苹果在不断放出我们预期之内消息（虽然其中一些细节确实带来了惊喜）的同时突然话锋一转，公布了其打造的Objective-C现代替代方案——也就是Swift。事实上，Swift编程语言曾经在史蒂夫•乔布斯创立NeXT公司之后被短暂用于项目开发。
Swift绝不是那种“今年年底之前将正式推出”类型的公告内容。就在同一天，iBooks商店当中上架了一份长达550页的Swift语言开发指南（苹果官方Swift教程9天完成汉化 可在线阅读）。开发人员们同时还能够体验Xcode 6 beta测试版，它允许我们利用这款新语言进行应用程序开发。总而言之，让Swift与Cocoa工具包顺畅协作所必需的一切要素及变更都已经准备到位，只剩开发者们莅临品鉴了。
尽管还没有正式利用Swift进行代码开发，但我们已经通读了整篇语言使用指南并查阅了苹果提供的代码示例。我们接下来要做的就是亲手使用这款语言，并体会苹果到底希望利用它实现哪些目标。
我们当初为什么要使用Objective-C？
当年NeXT公司建立之初，面向对象的编程机制尚未得到广泛普及，甚至没有几种语言能够真正实现这一构想。在那个时候，Objective-C可能是我们所能选择的最理想的方案——它一方面能够保持原有C代码的可用性以及开发者的传统使用习惯，另一方面则在此基础上添加了面向对象层。
但事实最终证明，NeXT公司是惟一一家使用该语言的主流厂商。从某种角度讲，这也带来一些积极的因素，毕竟该公司可以在心无旁骛的情况下从零开始、专注打造属于自己的整套Objective-C开发环境。顺理成章，任何一位打算利用该语言进行软件开发的使用者最终也不可避免地会用到NeXT的方案。举例来说，Objective-C当中的很多“语言特性”其实根本就不属于真正的语言特性;它们其实来自NeXT创造的基本类，也就是NSObject。此外，Coca当中的一部分设计模式，例如delegates的存在，也需要用到Objective-C当中的introspection功能——它的作用是以安全方式检测某个对象是否会对特定消息作出响应。
Objective-C那极为有限的使用面也带来负面影响，即迫使该语言不得不面向利基市场。在苹果继承了Objective-C时，技术人员马上着手为开发人员提供备用方案，也就是Carbon库，这样做是为了保证其开发方式更接近于传统的Mac软件开发流程。
iPhone SDK的迅速走红让一切有了转机，由于它只允许开发者选择Objective-C，这款面向对象的语言也开始席卷世界各地。似乎在一夜之间，开发 人员们开始前赴后继地使用Objective-C，其中很多人甚至将自己积累了多年的其它编程语言使用经验抛在了一边。这对于苹果来说无疑是个天大的好消息，但却也带来了一些问题。并不是每位开发者都心甘情愿地使用Objective-C并乐在其中，而苹果随后采取我们都熟知的方式解决这个问题——宣布Mac开发工作的未来将由Cocoa这款Objective-C框架承担。
Objective-C到底有什么问题？
Objective-C与苹果一直拥有难以置信的默契与出人意料的和谐。通过严格控制运行时并编写属于自己的编译器，这家技术巨头已经有能力在规避部分源自NeXT时代的语言局限性的同时为其加入一系列新功能，例如属性、垃圾收集机制以及垃圾收集机制的替代产物——自动引用计数。
但有些情况真的无法改变。由于仍然算是进行了一定程度扩展的C语言衍生产物，Objective-C只能利用C的方法来追踪复杂对象，也就是指针——指针基本上是对象占用的内存地址的第一个字节。一切的一切，从NSString到最为复杂的表视图，都需要利用其指针进行传递及通讯。
在大多数情况下，这种机制并不会产生问题。我们在编写复杂的应用程序时，基本不会意识到自己已经在不知不常见中用到了指针。但在某些极为罕见的情况下，这种机制也会弄糟一切并尝试访问错误的内存地址，从而导致程序崩溃或者带来意料之外的安全漏洞。事实上，C语言的其它一些特性也会造成类似的弊端;开发人员必须小心检查自己的代码长度并忍受相关限制，否则这些代码很可能游荡到内存中的其它随机位置。
除了这类先天不足的问题，Objective-C也随着时间推移而渐显老态。技术的不断发展让其它编程语言拥有了一些很难被移植到C语言这类古董开发方案中的卓越特性。最典型的例子就是所谓“generic”。在C语言中，如果我们希望对整数及浮点数值进行同样的数学去处，则必须为它们各自编写一个独立的函数——再加上专门用于其它无符号长整数以及双精度浮点数值的额外函数。在generic的帮助下，大家可以单独编写一个函数，即可轻松保证所有数值都被编译器正确认定为数字。
苹果公司显然可以在Objective-C的语法中添加一些重要特性——closure就是个很好的例子——但我们尚不清楚他们是否能随心所欲地实现此类特性添加。而且C语言的天然属性意味着它总是存在安全风险，毕竟所有稳定性与安全性任务都由一套单一而缺乏认真考量的编码器承担。可以说，是时候改变这一切了。
不过为什么不采取更简单的路线，直接选择另一种现有语言呢？这是由于Objective-C与Cocoa框架之间存在着紧密的联系，Objective-C所使用的一系列设计模式能够显著提高该框架的执行效率。而大部分现有主流替代方案都没办法以如此简洁的方式与现有Cocoa框架顺畅协作。有鉴于此，Swift应运而生。
拍摄于2014WWDC现场
好吧，但为什么是现在？
原因有几点。随着将开发体系向LLVM迁移，苹果已经牢牢控制住自己的运行时与工具链。这使得方案变化在实施（以及充分了解其后果）方面变得更为简单。苹果同时也在语言开发方面积累到了丰富的经验，并成功为Objective-C带来属性、自动引用计数以及closure等新特性。
作出这些变化也让苹果初步感受到了开发人员未来可能对调整作出怎样的反应。当苹果引入垃圾收集机制并向开发者们宣称“这是一套出色的方案”时，大家的反馈可以说有好有坏。而后来苹果引入自动引用计算并表示“这代表着未来”时，开发者们开始以更快的速度适应这一新情况。（苹果决定腰斩64位Carbon的决定无疑帮助开发者们提早预计到了新语言发布这一天的到来。）
所有这些早期变动帮助Swift中部分新特性的推出扫清了障碍。我们不妨回忆一下：closure与自动引用计数的面世时间还不太长，变量的处理方式与Objective-C的属性可以说相当接近。再有，因为苹果公司严格掌控着一切，因此同一套运行时可以并行支持Swift与Objective-C，即运行遗留代码与全新语言顺畅对接。总而言之，也许在五年前公布这样的决定会带来毁灭性的后果，但如今Swift已经具备了顺利接班的群众基础。
我们可能永远不知道苹果到底从多久以前就开始策划Swift编程语言的面世，但综合苹果在过去五年当中的实践经历，大家就会发现他们一直在不断积累经验、作出试探性动作并观察开发者社区到底对这类变动拥有怎样的容忍度。
大家懂我的意思吗？
如果大家打算编写一款新型编程语言，那么面临的首要难题就是在其易用性与可读性之间作出取舍。作为最为浅显的演示实例，我们选取了Swift开发者说明文档中的原始范例。如果我们写出以下代码，即使是对编程并不太熟悉的读者朋友也能从中看出点端倪。
- if thisIsTrue {
- that = that + 50
- } else {
- that = that + 20
- }
然而如果直接使用下面这种代码表达形式，恐怕大部分人都会感到一头雾水：
- that = that + (thisIsTrue ? 50 : 20)
上面两部分代码表达的其实是同样的意思。第二种明显更简洁、能够大大降低输入负担，而第一种则更加浅显、易于理解。编程语言的设计者们必须作出一系列决定来作好这两方面的权衡工作。这些决定最终可能给编程语言的命运带一深远影响，毕竟可读性影响到新手能否快速入门、理解代码样本所要表达的意思，或者在注释及为糟糕的情况下允许开发者快速接手项目。
除非大家有办法弄明白这些括号的含义，否则Objective-C在可读性方面的表现实在比较糟糕。如果大家编写了一条函数，旨在将两个字符串之间的文本提取出来，那么在大多数编程语言整个实现过程通常如下所示：
- myString.getTextBetweenBrackets( leftBracket, rightBracket);
但在实际使用中，这些变量往往不可能使用如此随意的命名方式。除非大家能把这条函数记在脑子里，否则肯定需要提醒自己这两个括号的添加顺序。Objective-C选择增加一部分录入成本以摆脱造成歧义的风险，由此编写出的同含义代码如下所示：
- [myString getTextBetweenLeftBracket: leftBracket andRightBracket: rightBracket];
写明每个参数的实际作用很有价值，这意味着我们可以增加参数的数量，但同时也会令变量名的自我解释能力随之下降。Swift则颇有种二者混合的意思，但同时也确切保留了下面这种表达方法：
- myString.getBracketedText ( LeftBracket: leftBracket, rightBracket: rightBracket );
这是一种非常重要的处理方式，在这里可读性得到了保证，不过每一位对Objective-C上述此类特性感到不满的开发者同样也会对Swift心生怨恨。（也许我们应该说可读性‘能够’得到保证，毕竟Swift也允许大家跳过将方法符号添加到括号当中的过程。苹果建议大家正确写明这些额外的文本，但我猜很多人根本不会鸟他们那一套。）
而在其它很多方面，Swift的可读性确实比较堪忧。最重要的是，单一字符的存在——例如一个感叹号或者问号——有可能给整个函数调用链产生巨大影响，甚至导致整行代码的执行效率完全改变。大家可以通过函数定义的方法来应对此类问题，例如设置默认值并为参数设定内部与外部名称，但这样做意味着我们必须认真阅读该函数的内容、以保证自己确切了解它的实际作用。
下面再来看另一个摘自Swift编程语言开发指南的示例，我们看看要如何定义一套行星枚举：
- case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
我们只需要为第一个条目添加一套索引。如果没有其它操作，编译会假设我们希望由1开始进行递增并自动依此进行。这样做的效果很好，也能帮助程序员节约很多时间。不过如果大家碰巧忘记了土星是太阳系第六颗行星——或者是碰巧处理的是一套相对难于记忆的内容列表——各位可能会发现自己需要将大把时间浪费在确定哪个数字到底对应什么条目身上。
这种特性对于我们在可读性与易写性方面的个人取向到底有什么影响？在我们深入使用这套语言并阅读更多样本代码之前，答案尚无法确定。就目前的情况看，大量Swift代码恐怕很难通过直接阅读了解其含义，但我们觉得这一点在实际使用中并非关注的首要重点。大部分程序员可能更青睐于Swift那相对压缩化的语法，但该语言的灵活性可能意味着人们会有意无意编写出在实际运行中没有问题、但其他用户却很难理解的代码内容。
#p#
语言基础：多种多样的选择
正如我们之前所提到，开发人员可以有选择地在函数调用当中忽略方法符号信息。事实上，Swift为大部分使用方式提供了多种选择。想用分号来定义代码行的结束？没问题，只要我们愿意。如若不然，编译器会自行推断出一个连贯性语句的结束并采取相应行动。想为逻辑求值加个括号，就像if声明那样？如果大家认为这样有助于代码的阅读与理解，完全可以实现。不过编译器本身并不需要将这些符号纳入考虑范围。
选择如此丰富，看起来我们完全可以在自己的自主取舍之下随意编写Swift代码，甚至能够写出与其它编程语言完全不同的表达方式来。事实上，我们完全可以在Swift代码中动动歪脑筋，让其它语言的用户完全看不懂咱们在干什么。
作为Swift语言中的重要组成部分而非单纯的字符数组，其字符串与Java看起来相当类似。与此同时，字符串与数字也更像是被当作对象进行处理，这是因为它们拥有与自身相关的属性。如果大家希望弄明白一个UInt8（也就是8位无符号整数）当中能够安全存放的最大数值是多少，可以调用Uint8.max。如果大家打算想对超出上述结果的数字进行赋值，运行时会将其截断并限制为最大数值，除非我们像操作汽车日程表那样明确要求其继续进行。作为一种理想的体验方式，大家可以利用科学记数法将该值指派给浮点变量。
我们可以利用type对这些数值设为变量，也可以简单为某个变量指定某个值，而Swift会我们希望使用的实际type到底是哪一种（也就是说，如果大家为某个变量赋值为5.7，Swift会将该变量设置为双精度浮点形式）。Swift还鼓励大家在处理不打算变更的数值时将其设为常数;相对于“var”，现在我们使用“let”来进行赋值。
通常的逻辑、数位以及数值运算符在Swift中一应俱全——例如通过+来实现字符串连接。大家还可以定义自己的运算符，而苹果提供两个新的运算符以进行对象比较。原本用于测试两个对象的逻辑==运算符现在的作用是检测二者是否相等。因此在数组这类实例当中，它会检查二者是否包含同样的对象。为了确定二者是否指向同样的内存地址，现在我们可以使用===。除此之外，范围运算符也没有缺席;0…50代表着二者之间的每一个整数，包括0与50本身，这个符号能在编写简单循环时帮上大忙。
常用的for/do/while循环集合仍然存在，if/else声明自然也不例外。真正变动较大的是switch/case声明。在大多数语言中，我们必须明确让多个case声明保持执行，这也是引发错误的常见原因。在Swift中，大家必须明确告知编译器自己是否希望进入下一个case声明。大家还可以标记不同的循环以及逻辑运算，而后利用“break myLabel”指明自己要打破嵌套运算体系中的具体哪个部分。
Swift语言还包含数组与字典，二者能够与任何数值及字符串值顺利协作——例如将字符串与整数混合到同一个数组当中。由此带来的函数包括.insert与.count等等，它们允许大家访问并操作自身所存放的值。
结构、枚举与对象
C语言并不像Objective-C那样能够提供对象类分类机制，但它却允许结构的存在——也就是一套相关数据与方法的集合。结构在Swift当中同样适用，在这里它们类似于类但却不具备继承性、析构器以及引用计数等特性。它们的传递始终依靠复制来实现。Swift中的类与Objective-C中的类基本一致，并以引用的方式实现传递。
Swift与Objective-C之间最大的区别在于枚举器，苹果将其称为“一级type”。枚举器可以拥有构析器且不限于相关整数值。以前面的代码为例，大家可以为其指定星球。火星的值为4，也可以将值设为“太阳系第四颗行星”。事实上，大家可以将火星设为一套包含四个数字的集合，分别是该星球的质量、半径、公转轨道周期与公转轨道距离。这些值随后可以在代码的其它部分进行检索。
这种模糊的处理方式也延伸到了基本变量层面。数组与字典显然适用于大多数同样可用于NSArray与NSDictionary类的方法。全部主要条目（包括类以及结构等等）之间的相似性有助于我们摆脱面向对象的Cocoa与更具C特性的组成部分之间偶尔出现的冲突状况。
苹果一直鼓励开发者们访问那些由使用“setter”与“getter”方法的对象所持有的变量，而Swift将这种习惯转化成了标准形式，并将它们与普通类定义区分开来。现在每一个类都拥有一个“将要变更”的方法与一个“已经变更”的方法，这有助于在某个变量发生变化时保持同步值的相互依赖性。此外，initialization方法也被挑选了出来，这样子类就会以特定顺序调用其super的构析器并对其内容进行整理。
在Objective-C中被取消、却在Swift中得以回归的特性之一就是协议，在协议中类可以将自身声明为保证提供一系列特定功能。因此，“webPage”协议能够保证其对某个URL、页面文本乃至其它内容进行访问。有鉴于此，我们能够创建一系列类以实现webPage功能并将其准确交换到需要执行的位置。
类别同样被重新引入，只不过经过了重新命名与功能强化。类别非常擅长向现有类中添加功能。举例来说，大家可以将前面提到的括号文本功能作为类别添加到NSString当中，而我们在应用程序当中创建的第一个NNString都会对其作出响应。类别现在被重新命名为扩展，能够将新的构析器与变量添加到它们所修改的类当中。它们能够修改基本语言特性，例如浮点数字。
还有另外一种特殊的值类型，被称为“tuple”，它以囊括多个值的包的形式运作。虽然一个函数只能返回一个条目，但该条目可以是tuple、因此可以包含多种不同类型的变量。当我们访问一个tuple时，则可以为其中的每一个值设定变量（或者常数）并开始使用。
closures、generics以及运算符重载
苹果引入了block的概念，即小型代码块，它能够在应用程序内部传递并指向数次操作系统操作工之前的版本。它们非常适合处理会话之类的任务，这类任务通常需要在用户进行关闭操作之后继续执行一部分代码。大家可以将对应代码以block形式存放在会话能够执行的位置（即与其保持逻辑归属关系），同时将其交付给会话，这样只有在用户按下按钮时才会付诸执行。这不仅非常便利，而且也是一种改进代码可读性的良好途径。因此，block顺理成章地重新回归Swift，这一次它拥有了自己的正式名称——closures。
苹果的Swift开发指南现在已经以免费形式登陆iBooks
在C语言当中同样可以使用代码block。函数的末尾总是以内存中的地址作结，而大家可以为该函数创建一个指针。Swift提供类似的功能，允许大家设置变量、用以容纳任何与特定标记相匹配的函数。这是由closures为起点构成的卓越逻辑扩展，而且以抽象形式规避了其面向实际内存地址可能带来的风险。
正如我们之前所提到，Swift加入了generics，也就是指那些能够与多种不同变量类型相协作的函数。举例来说，大家可以创建一个求某数组全部内容加值总和的generic函数，而不必考虑该数组当中所存放的数字到底属于哪种类型。大家还可以通过设置generics来规定它们只能输入到特定几种协议当中，从而实现对对象类型的限定。举例来说，Swift当中的全部基础变量类型都遵循Equatable协议，该协议允许这些变量响应==运算符。
很明显，所有遵循Equatable协议的定制类也符合上述情况，就是说它们也一定能力对==运算符作出响应。为了实现这一点，Swift引入了一项名为运算符重载的功能，它的存在允许程序员在定制类中定义如何使用基础运算符。因此，如果大家已经设定了某个定制类来代表硬盘驱动器，则可以重载==来检查该驱动器的制造商、存储容量、转速以及其它各种参数。大家还可以重载+来轻松添加新的驱动器，或者将两个运算符组合使用。
还有什么没提到？
可以肯定，Swift当中还缺乏几十种大家常用的语言所提供的便利特性，也认同苹果最新推出的研发成果在起步阶段仍然比较孱弱。不过最引人注意的是，目前Swift缺少一套完整的错误捕捉机制。没错，编译器目前在追踪常见错误方面已经相当智能，而且该语言的特性也通过多种智能化方式规避了对零对象进行误操作的可能性。
但无论这款编程语言及其编译器有多么智能，人们（比如说我）总会不失时机地犯下错误并把一切搞砸。而且我们宁愿程序优雅地报错，也不愿意看到它们突然崩溃并陷入瘫痪。
当然，目前的Swift还属于beta测试版本，而且苹果公司几乎肯定会为这款核心语言设计可扩展性——我相信这帮技术人员还对向Objective-C中添加新特性的痛苦经历记忆犹新。如果开发者们广泛就这一问题提出反馈（当然，大家也可以根据自己的感受向苹果反映其它存在于Swift当中的弊端），尚处于早期测试阶段的Swift仍然有可能拨乱反正、搞定影响使用效果的各类短板。但愿苹果不会站出来以“没人需要它”为理由对我们的声音视而不见——其实这只是种无谓的担忧，正如苹果开玩笑称他们将把下一代OS X系统命名为“Weed（大麻）”一样。
Swift开发效果截图
它有什么好处？
从诸多角度来讲，Swift并不是一次彻底的颠覆。苹果对某些特定设计模式青眼有加，他们也相继推出了Objective-C与Cocoa来鼓励开发者采用这些模式。Swift做的其实是同样的工作，即进一步对此类设计模式加以规范、以扼止有所上扬的模式自由化趋势（例如属性）。Swift带来的大多数特性在其它现有编程语言当中都能找到，因此不少开发者会在使用过程中产生熟悉之感。此次添加进来的新特性总体而言非常出色，同时被淘汰出去的机制（例如指针算法）也确实属于困扰了开发者很长时间的大麻烦。
从这个意义上出发，Swift是一套优秀的、以Objective-C为基础的增量化升级方案。所有的显著变化都体现在基本语法层面。使用分号与括号——或者干脆不使用，这都没关系。将方法标记包含在函数调用当中也并无不可——只要大家愿意，一切皆有可能。通过这样与那样的实例，我们发现Swift确实是一款允许大家选择自己最适语法及风格的出色编程语言，在很多情况下还能帮助我们将输入内容控制在最低范围——还是那句话，只要我们愿意。
大部分新特性都已经出现在其它语言当中，而语法的变化也将Swift逐渐摆脱了Objective-C的独特性。我们通常都可以利用完全不同的语法编写出同样含义的代码。这一切让Swift破除与其它编程语言之间的障碍高墙，使之成为很多开发者熟悉且乐于接受的新型语言。这样的设定非常重要，而且有利于苹果吸引那些此前从未接触过C语言的开发者加入到iOS应用开发阵营当中。当然，这些新入门的开发者仍然需要学习苹果框架的设计模式，但至少他们不用再同时面对一套自己从未接触过的编程语言了。
总体而言，以上因素非常积极、相信能够带来不错的用户反响。如果苹果坚持选择单一的编程风格，那么其中的一部分要求也许会与我们的开发习惯相去甚远。然而在灵活性的支持下，我们仍然能够以非常接近自身熟知的方式进行开发工作。
不过这还并不是全部。Swift当中仍然存在着一部分我个人比较反感的特定语法，而且在某些情况下一个字符的谬误就会将整行代码的意义失之千里。综合来看，语法的变动会让由多位开发者负责的大型Swift开发项目在管理上更困难——至少比Objective-C项目更困难。
苹果公司接下来要做什么？
很明显，Swift目前还处于起步阶段。这款编程语言降低了大部分常见失误的发生机率，并彻底规避了某些糟糕实践方式的出现可能性。如果大家愿意，完全可以在Swift中以非常简洁的方式编写代码，这能够大大降低开发者的工作压力。它引入了多项优秀的新特性，应该能够帮助开发人员提高工作效率。这一切都是其积极的一面。
不过从宏观角度看，苹果决定也许会惹恼很多像我这样的开发者。我花了很多时间来学习如何顺畅使用自动释放池，我的应用程序并不会导致内存溢出，因此我觉得自己没必要了解那么多语法来避免自动引用计数由于循环引用而最终无法被回收。我对于使用符号来访问属性没啥兴趣，因此我只在别无选择的时候才使用符号。简言之，我安于现状、不喜欢被迫接受一种新的语言。
像我这样的开发者群体直接导致运行时与编译器团队无法拿出优秀的解决方案。如果每个人都能使用同一项功能特性，那么技术团队可以轻松抛开传统支持任务、转而对目前仍处于活跃状态的事物进行优化。更小的内存空间占用与更出色的性能表现意味着更低的组件成本与更理想的电池续航能力，这一切对于苹果公司而言都是值得为之奋斗的目标。
苹果承诺Swift会带来更出色的性能表现，大家通过一些细节已经可以看出点端倪。常数在Swift中所占的比重非常大，其意义也极为显著。如果我们要制作一款股票追踪应用，股票的价格当然每秒钟都会发生变化，不过股票的名称与对应符号却很少变动，而且即使出现这种情况、我们也能够轻松创建一个全新对象来应对。将股票的名称与相关符号声明为常量，这样大家就不必以安全进程方式对其进行变更。根据我的推测，编译器还能够根据常量的使用情况作出进一步优化。
一场巨大的变革即将出现，我们这些保守的顽固派应当清醒地认识到这一点。从现在开始的两到三年之后，苹果可能会宣布Swift才代表着未来并准备逐步放弃Objective-C，我们对这样的消息不该感到惊讶。而且到那时我也不会对这一切感到懊恼，因为我已经在这几年中允许了解了这款新语言的使用方法。
原文：A Fast Look at Swift: Apple’s New Programming Language
核子可乐译
