【51CTO譯文】無論結果是好是壞，蘋果打造的全新語言都將讓我們以自己的方式處理開發(fā)工作。

[[114347]]

對于任何一位蘋果公司之外的關注者而言，Swift語言的突然面世究竟會帶來怎樣的后續(xù)影響都實在難以斷言。就在本屆WWDC大會的主題演講中，蘋果在不斷放出我們預期之內(nèi)消息（雖然其中一些細節(jié)確實帶來了驚喜）的同時突然話鋒一轉(zhuǎn)，公布了其打造的Objective-C現(xiàn)代替代方案——也就是Swift。事實上，Swift編程語言曾經(jīng)在史蒂夫•喬布斯創(chuàng)立NeXT公司之后被短暫用于項目開發(fā)。

Swift絕不是那種“今年年底之前將正式推出”類型的公告內(nèi)容。就在同一天，iBooks商店當中上架了一份長達550頁的Swift語言開發(fā)指南（蘋果官方Swift教程9天完成漢化 可在線閱讀）。開發(fā)人員們同時還能夠體驗Xcode 6 beta測試版，它允許我們利用這款新語言進行應用程序開發(fā)?？偠灾?，讓Swift與Cocoa工具包順暢協(xié)作所必需的一切要素及變更都已經(jīng)準備到位，只剩開發(fā)者們蒞臨品鑒了。

盡管還沒有正式利用Swift進行代碼開發(fā)，但我們已經(jīng)通讀了整篇語言使用指南并查閱了蘋果提供的代碼示例。我們接下來要做的就是親手使用這款語言，并體會蘋果到底希望利用它實現(xiàn)哪些目標。

我們當初為什么要使用Objective-C？

當年NeXT公司建立之初，面向?qū)ο蟮木幊虣C制尚未得到廣泛普及，甚至沒有幾種語言能夠真正實現(xiàn)這一構想。在那個時候，Objective-C可能是我們所能選擇的最理想的方案——它一方面能夠保持原有C代碼的可用性以及開發(fā)者的傳統(tǒng)使用習慣，另一方面則在此基礎上添加了面向?qū)ο髮印?/p>

但事實最終證明，NeXT公司是惟一一家使用該語言的主流廠商。從某種角度講，這也帶來一些積極的因素，畢竟該公司可以在心無旁騖的情況下從零開始、專注打造屬于自己的整套Objective-C開發(fā)環(huán)境。順理成章，任何一位打算利用該語言進行軟件開發(fā)的使用者最終也不可避免地會用到NeXT的方案。舉例來說，Objective-C當中的很多“語言特性”其實根本就不屬于真正的語言特性;它們其實來自NeXT創(chuàng)造的基本類，也就是NSObject。此外，Coca當中的一部分設計模式，例如delegates的存在，也需要用到Objective-C當中的introspection功能——它的作用是以安全方式檢測某個對象是否會對特定消息作出響應。

Objective-C那極為有限的使用面也帶來負面影響，即迫使該語言不得不面向利基市場。在蘋果繼承了Objective-C時，技術人員馬上著手為開發(fā)人員提供備用方案，也就是Carbon庫，這樣做是為了保證其開發(fā)方式更接近于傳統(tǒng)的Mac軟件開發(fā)流程。

iPhone SDK的迅速走紅讓一切有了轉(zhuǎn)機，由于它只允許開發(fā)者選擇Objective-C，這款面向?qū)ο蟮恼Z言也開始席卷世界各地。似乎在一夜之間，開發(fā) 人員們開始前赴后繼地使用Objective-C，其中很多人甚至將自己積累了多年的其它編程語言使用經(jīng)驗拋在了一邊。這對于蘋果來說無疑是個天大的好消息，但卻也帶來了一些問題。并不是每位開發(fā)者都心甘情愿地使用Objective-C并樂在其中，而蘋果隨后采取我們都熟知的方式解決這個問題——宣布Mac開發(fā)工作的未來將由Cocoa這款Objective-C框架承擔。

Objective-C到底有什么問題？

Objective-C與蘋果一直擁有難以置信的默契與出人意料的和諧。通過嚴格控制運行時并編寫屬于自己的編譯器，這家技術巨頭已經(jīng)有能力在規(guī)避部分源自NeXT時代的語言局限性的同時為其加入一系列新功能，例如屬性、垃圾收集機制以及垃圾收集機制的替代產(chǎn)物——自動引用計數(shù)。

但有些情況真的無法改變。由于仍然算是進行了一定程度擴展的C語言衍生產(chǎn)物，Objective-C只能利用C的方法來追蹤復雜對象，也就是指針——指針基本上是對象占用的內(nèi)存地址的第一個字節(jié)。一切的一切，從NSString到最為復雜的表視圖，都需要利用其指針進行傳遞及通訊。

在大多數(shù)情況下，這種機制并不會產(chǎn)生問題。我們在編寫復雜的應用程序時，基本不會意識到自己已經(jīng)在不知不常見中用到了指針。但在某些極為罕見的情況下，這種機制也會弄糟一切并嘗試訪問錯誤的內(nèi)存地址，從而導致程序崩潰或者帶來意料之外的安全漏洞。事實上，C語言的其它一些特性也會造成類似的弊端;開發(fā)人員必須小心檢查自己的代碼長度并忍受相關限制，否則這些代碼很可能游蕩到內(nèi)存中的其它隨機位置。

除了這類先天不足的問題，Objective-C也隨著時間推移而漸顯老態(tài)。技術的不斷發(fā)展讓其它編程語言擁有了一些很難被移植到C語言這類古董開發(fā)方案中的卓越特性。最典型的例子就是所謂“generic”。在C語言中，如果我們希望對整數(shù)及浮點數(shù)值進行同樣的數(shù)學去處，則必須為它們各自編寫一個獨立的函數(shù)——再加上專門用于其它無符號長整數(shù)以及雙精度浮點數(shù)值的額外函數(shù)。在generic的幫助下，大家可以單獨編寫一個函數(shù)，即可輕松保證所有數(shù)值都被編譯器正確認定為數(shù)字。

蘋果公司顯然可以在Objective-C的語法中添加一些重要特性——closure就是個很好的例子——但我們尚不清楚他們是否能隨心所欲地實現(xiàn)此類特性添加。而且C語言的天然屬性意味著它總是存在安全風險，畢竟所有穩(wěn)定性與安全性任務都由一套單一而缺乏認真考量的編碼器承擔?？梢哉f，是時候改變這一切了。

不過為什么不采取更簡單的路線，直接選擇另一種現(xiàn)有語言呢？這是由于Objective-C與Cocoa框架之間存在著緊密的聯(lián)系，Objective-C所使用的一系列設計模式能夠顯著提高該框架的執(zhí)行效率。而大部分現(xiàn)有主流替代方案都沒辦法以如此簡潔的方式與現(xiàn)有Cocoa框架順暢協(xié)作。有鑒于此，Swift應運而生。

[[114348]]

拍攝于2014WWDC現(xiàn)場

好吧，但為什么是現(xiàn)在？

原因有幾點。隨著將開發(fā)體系向LLVM遷移，蘋果已經(jīng)牢牢控制住自己的運行時與工具鏈。這使得方案變化在實施（以及充分了解其后果）方面變得更為簡單。蘋果同時也在語言開發(fā)方面積累到了豐富的經(jīng)驗，并成功為Objective-C帶來屬性、自動引用計數(shù)以及closure等新特性。

作出這些變化也讓蘋果初步感受到了開發(fā)人員未來可能對調(diào)整作出怎樣的反應。當蘋果引入垃圾收集機制并向開發(fā)者們宣稱“這是一套出色的方案”時，大家的反饋可以說有好有壞。而后來蘋果引入自動引用計算并表示“這代表著未來”時，開發(fā)者們開始以更快的速度適應這一新情況。（蘋果決定腰斬64位Carbon的決定無疑幫助開發(fā)者們提早預計到了新語言發(fā)布這一天的到來。）

所有這些早期變動幫助Swift中部分新特性的推出掃清了障礙。我們不妨回憶一下：closure與自動引用計數(shù)的面世時間還不太長，變量的處理方式與Objective-C的屬性可以說相當接近。再有，因為蘋果公司嚴格掌控著一切，因此同一套運行時可以并行支持Swift與Objective-C，即運行遺留代碼與全新語言順暢對接?？偠灾苍S在五年前公布這樣的決定會帶來毀滅性的后果，但如今Swift已經(jīng)具備了順利接班的群眾基礎。

我們可能永遠不知道蘋果到底從多久以前就開始策劃Swift編程語言的面世，但綜合蘋果在過去五年當中的實踐經(jīng)歷，大家就會發(fā)現(xiàn)他們一直在不斷積累經(jīng)驗、作出試探性動作并觀察開發(fā)者社區(qū)到底對這類變動擁有怎樣的容忍度。

大家懂我的意思嗎？

如果大家打算編寫一款新型編程語言，那么面臨的首要難題就是在其易用性與可讀性之間作出取舍。作為最為淺顯的演示實例，我們選取了Swift開發(fā)者說明文檔中的原始范例。如果我們寫出以下代碼，即使是對編程并不太熟悉的讀者朋友也能從中看出點端倪。

if thisIsTrue { 
 
    that = that + 50 
 
} else { 
 
    that = that + 20 
 
} 

然而如果直接使用下面這種代碼表達形式，恐怕大部分人都會感到一頭霧水：

that = that + (thisIsTrue ? 50 : 20) 

上面兩部分代碼表達的其實是同樣的意思。第二種明顯更簡潔、能夠大大降低輸入負擔，而第一種則更加淺顯、易于理解。編程語言的設計者們必須作出一系列決定來作好這兩方面的權衡工作。這些決定最終可能給編程語言的命運帶一深遠影響，畢竟可讀性影響到新手能否快速入門、理解代碼樣本所要表達的意思，或者在注釋及為糟糕的情況下允許開發(fā)者快速接手項目。

除非大家有辦法弄明白這些括號的含義，否則Objective-C在可讀性方面的表現(xiàn)實在比較糟糕。如果大家編寫了一條函數(shù)，旨在將兩個字符串之間的文本提取出來，那么在大多數(shù)編程語言整個實現(xiàn)過程通常如下所示：

myString.getTextBetweenBrackets( leftBracket, rightBracket); 

但在實際使用中，這些變量往往不可能使用如此隨意的命名方式。除非大家能把這條函數(shù)記在腦子里，否則肯定需要提醒自己這兩個括號的添加順序。Objective-C選擇增加一部分錄入成本以擺脫造成歧義的風險，由此編寫出的同含義代碼如下所示：

[myString getTextBetweenLeftBracket: leftBracket andRightBracket: rightBracket]; 

寫明每個參數(shù)的實際作用很有價值，這意味著我們可以增加參數(shù)的數(shù)量，但同時也會令變量名的自我解釋能力隨之下降。Swift則頗有種二者混合的意思，但同時也確切保留了下面這種表達方法：

myString.getBracketedText ( LeftBracket: leftBracket, rightBracket: rightBracket ); 

這是一種非常重要的處理方式，在這里可讀性得到了保證，不過每一位對Objective-C上述此類特性感到不滿的開發(fā)者同樣也會對Swift心生怨恨。（也許我們應該說可讀性‘能夠’得到保證，畢竟Swift也允許大家跳過將方法符號添加到括號當中的過程。蘋果建議大家正確寫明這些額外的文本，但我猜很多人根本不會鳥他們那一套。）

而在其它很多方面，Swift的可讀性確實比較堪憂。最重要的是，單一字符的存在——例如一個感嘆號或者問號——有可能給整個函數(shù)調(diào)用鏈產(chǎn)生巨大影響，甚至導致整行代碼的執(zhí)行效率完全改變。大家可以通過函數(shù)定義的方法來應對此類問題，例如設置默認值并為參數(shù)設定內(nèi)部與外部名稱，但這樣做意味著我們必須認真閱讀該函數(shù)的內(nèi)容、以保證自己確切了解它的實際作用。

下面再來看另一個摘自Swift編程語言開發(fā)指南的示例，我們看看要如何定義一套行星枚舉：

case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune 

我們只需要為第一個條目添加一套索引。如果沒有其它操作，編譯會假設我們希望由1開始進行遞增并自動依此進行。這樣做的效果很好，也能幫助程序員節(jié)約很多時間。不過如果大家碰巧忘記了土星是太陽系第六顆行星——或者是碰巧處理的是一套相對難于記憶的內(nèi)容列表——各位可能會發(fā)現(xiàn)自己需要將大把時間浪費在確定哪個數(shù)字到底對應什么條目身上。

這種特性對于我們在可讀性與易寫性方面的個人取向到底有什么影響？在我們深入使用這套語言并閱讀更多樣本代碼之前，答案尚無法確定。就目前的情況看，大量Swift代碼恐怕很難通過直接閱讀了解其含義，但我們覺得這一點在實際使用中并非關注的首要重點。大部分程序員可能更青睞于Swift那相對壓縮化的語法，但該語言的靈活性可能意味著人們會有意無意編寫出在實際運行中沒有問題、但其他用戶卻很難理解的代碼內(nèi)容。

#p#

語言基礎：多種多樣的選擇

正如我們之前所提到，開發(fā)人員可以有選擇地在函數(shù)調(diào)用當中忽略方法符號信息。事實上，Swift為大部分使用方式提供了多種選擇。想用分號來定義代碼行的結束？沒問題，只要我們愿意。如若不然，編譯器會自行推斷出一個連貫性語句的結束并采取相應行動。想為邏輯求值加個括號，就像if聲明那樣？如果大家認為這樣有助于代碼的閱讀與理解，完全可以實現(xiàn)。不過編譯器本身并不需要將這些符號納入考慮范圍。

選擇如此豐富，看起來我們完全可以在自己的自主取舍之下隨意編寫Swift代碼，甚至能夠?qū)懗雠c其它編程語言完全不同的表達方式來。事實上，我們完全可以在Swift代碼中動動歪腦筋，讓其它語言的用戶完全看不懂咱們在干什么。

作為Swift語言中的重要組成部分而非單純的字符數(shù)組，其字符串與Java看起來相當類似。與此同時，字符串與數(shù)字也更像是被當作對象進行處理，這是因為它們擁有與自身相關的屬性。如果大家希望弄明白一個UInt8（也就是8位無符號整數(shù)）當中能夠安全存放的最大數(shù)值是多少，可以調(diào)用Uint8.max。如果大家打算想對超出上述結果的數(shù)字進行賦值，運行時會將其截斷并限制為最大數(shù)值，除非我們像操作汽車日程表那樣明確要求其繼續(xù)進行。作為一種理想的體驗方式，大家可以利用科學記數(shù)法將該值指派給浮點變量。

我們可以利用type對這些數(shù)值設為變量，也可以簡單為某個變量指定某個值，而Swift會我們希望使用的實際type到底是哪一種（也就是說，如果大家為某個變量賦值為5.7，Swift會將該變量設置為雙精度浮點形式）。Swift還鼓勵大家在處理不打算變更的數(shù)值時將其設為常數(shù);相對于“var”，現(xiàn)在我們使用“let”來進行賦值。

通常的邏輯、數(shù)位以及數(shù)值運算符在Swift中一應俱全——例如通過+來實現(xiàn)字符串連接。大家還可以定義自己的運算符，而蘋果提供兩個新的運算符以進行對象比較。原本用于測試兩個對象的邏輯==運算符現(xiàn)在的作用是檢測二者是否相等。因此在數(shù)組這類實例當中，它會檢查二者是否包含同樣的對象。為了確定二者是否指向同樣的內(nèi)存地址，現(xiàn)在我們可以使用===。除此之外，范圍運算符也沒有缺席;0…50代表著二者之間的每一個整數(shù)，包括0與50本身，這個符號能在編寫簡單循環(huán)時幫上大忙。

常用的for/do/while循環(huán)集合仍然存在，if/else聲明自然也不例外。真正變動較大的是switch/case聲明。在大多數(shù)語言中，我們必須明確讓多個case聲明保持執(zhí)行，這也是引發(fā)錯誤的常見原因。在Swift中，大家必須明確告知編譯器自己是否希望進入下一個case聲明。大家還可以標記不同的循環(huán)以及邏輯運算，而后利用“break myLabel”指明自己要打破嵌套運算體系中的具體哪個部分。

Swift語言還包含數(shù)組與字典，二者能夠與任何數(shù)值及字符串值順利協(xié)作——例如將字符串與整數(shù)混合到同一個數(shù)組當中。由此帶來的函數(shù)包括.insert與.count等等，它們允許大家訪問并操作自身所存放的值。

結構、枚舉與對象

C語言并不像Objective-C那樣能夠提供對象類分類機制，但它卻允許結構的存在——也就是一套相關數(shù)據(jù)與方法的集合。結構在Swift當中同樣適用，在這里它們類似于類但卻不具備繼承性、析構器以及引用計數(shù)等特性。它們的傳遞始終依靠復制來實現(xiàn)。Swift中的類與Objective-C中的類基本一致，并以引用的方式實現(xiàn)傳遞。

Swift與Objective-C之間最大的區(qū)別在于枚舉器，蘋果將其稱為“一級type”。枚舉器可以擁有構析器且不限于相關整數(shù)值。以前面的代碼為例，大家可以為其指定星球?；鹦堑闹禐?，也可以將值設為“太陽系第四顆行星”。事實上，大家可以將火星設為一套包含四個數(shù)字的集合，分別是該星球的質(zhì)量、半徑、公轉(zhuǎn)軌道周期與公轉(zhuǎn)軌道距離。這些值隨后可以在代碼的其它部分進行檢索。

這種模糊的處理方式也延伸到了基本變量層面。數(shù)組與字典顯然適用于大多數(shù)同樣可用于NSArray與NSDictionary類的方法。全部主要條目（包括類以及結構等等）之間的相似性有助于我們擺脫面向?qū)ο蟮腃ocoa與更具C特性的組成部分之間偶爾出現(xiàn)的沖突狀況。

蘋果一直鼓勵開發(fā)者們訪問那些由使用“setter”與“getter”方法的對象所持有的變量，而Swift將這種習慣轉(zhuǎn)化成了標準形式，并將它們與普通類定義區(qū)分開來?，F(xiàn)在每一個類都擁有一個“將要變更”的方法與一個“已經(jīng)變更”的方法，這有助于在某個變量發(fā)生變化時保持同步值的相互依賴性。此外，initialization方法也被挑選了出來，這樣子類就會以特定順序調(diào)用其super的構析器并對其內(nèi)容進行整理。

在Objective-C中被取消、卻在Swift中得以回歸的特性之一就是協(xié)議，在協(xié)議中類可以將自身聲明為保證提供一系列特定功能。因此，“webPage”協(xié)議能夠保證其對某個URL、頁面文本乃至其它內(nèi)容進行訪問。有鑒于此，我們能夠創(chuàng)建一系列類以實現(xiàn)webPage功能并將其準確交換到需要執(zhí)行的位置。

類別同樣被重新引入，只不過經(jīng)過了重新命名與功能強化。類別非常擅長向現(xiàn)有類中添加功能。舉例來說，大家可以將前面提到的括號文本功能作為類別添加到NSString當中，而我們在應用程序當中創(chuàng)建的第一個NNString都會對其作出響應。類別現(xiàn)在被重新命名為擴展，能夠?qū)⑿碌臉嬑銎髋c變量添加到它們所修改的類當中。它們能夠修改基本語言特性，例如浮點數(shù)字。

還有另外一種特殊的值類型，被稱為“tuple”，它以囊括多個值的包的形式運作。雖然一個函數(shù)只能返回一個條目，但該條目可以是tuple、因此可以包含多種不同類型的變量。當我們訪問一個tuple時，則可以為其中的每一個值設定變量（或者常數(shù)）并開始使用。

closures、generics以及運算符重載

蘋果引入了block的概念，即小型代碼塊，它能夠在應用程序內(nèi)部傳遞并指向數(shù)次操作系統(tǒng)操作工之前的版本。它們非常適合處理會話之類的任務，這類任務通常需要在用戶進行關閉操作之后繼續(xù)執(zhí)行一部分代碼。大家可以將對應代碼以block形式存放在會話能夠執(zhí)行的位置（即與其保持邏輯歸屬關系），同時將其交付給會話，這樣只有在用戶按下按鈕時才會付諸執(zhí)行。這不僅非常便利，而且也是一種改進代碼可讀性的良好途徑。因此，block順理成章地重新回歸Swift，這一次它擁有了自己的正式名稱——closures。

蘋果的Swift開發(fā)指南現(xiàn)在已經(jīng)以免費形式登陸iBooks

在C語言當中同樣可以使用代碼block。函數(shù)的末尾總是以內(nèi)存中的地址作結，而大家可以為該函數(shù)創(chuàng)建一個指針。Swift提供類似的功能，允許大家設置變量、用以容納任何與特定標記相匹配的函數(shù)。這是由closures為起點構成的卓越邏輯擴展，而且以抽象形式規(guī)避了其面向?qū)嶋H內(nèi)存地址可能帶來的風險。

正如我們之前所提到，Swift加入了generics，也就是指那些能夠與多種不同變量類型相協(xié)作的函數(shù)。舉例來說，大家可以創(chuàng)建一個求某數(shù)組全部內(nèi)容加值總和的generic函數(shù)，而不必考慮該數(shù)組當中所存放的數(shù)字到底屬于哪種類型。大家還可以通過設置generics來規(guī)定它們只能輸入到特定幾種協(xié)議當中，從而實現(xiàn)對對象類型的限定。舉例來說，Swift當中的全部基礎變量類型都遵循Equatable協(xié)議，該協(xié)議允許這些變量響應==運算符。

很明顯，所有遵循Equatable協(xié)議的定制類也符合上述情況，就是說它們也一定能力對==運算符作出響應。為了實現(xiàn)這一點，Swift引入了一項名為運算符重載的功能，它的存在允許程序員在定制類中定義如何使用基礎運算符。因此，如果大家已經(jīng)設定了某個定制類來代表硬盤驅(qū)動器，則可以重載==來檢查該驅(qū)動器的制造商、存儲容量、轉(zhuǎn)速以及其它各種參數(shù)。大家還可以重載+來輕松添加新的驅(qū)動器，或者將兩個運算符組合使用。

還有什么沒提到？

可以肯定，Swift當中還缺乏幾十種大家常用的語言所提供的便利特性，也認同蘋果最新推出的研發(fā)成果在起步階段仍然比較孱弱。不過最引人注意的是，目前Swift缺少一套完整的錯誤捕捉機制。沒錯，編譯器目前在追蹤常見錯誤方面已經(jīng)相當智能，而且該語言的特性也通過多種智能化方式規(guī)避了對零對象進行誤操作的可能性。

但無論這款編程語言及其編譯器有多么智能，人們（比如說我）總會不失時機地犯下錯誤并把一切搞砸。而且我們寧愿程序優(yōu)雅地報錯，也不愿意看到它們突然崩潰并陷入癱瘓。

當然，目前的Swift還屬于beta測試版本，而且蘋果公司幾乎肯定會為這款核心語言設計可擴展性——我相信這幫技術人員還對向Objective-C中添加新特性的痛苦經(jīng)歷記憶猶新。如果開發(fā)者們廣泛就這一問題提出反饋（當然，大家也可以根據(jù)自己的感受向蘋果反映其它存在于Swift當中的弊端），尚處于早期測試階段的Swift仍然有可能撥亂反正、搞定影響使用效果的各類短板。但愿蘋果不會站出來以“沒人需要它”為理由對我們的聲音視而不見——其實這只是種無謂的擔憂，正如蘋果開玩笑稱他們將把下一代OS X系統(tǒng)命名為“Weed（大麻）”一樣。

Swift開發(fā)效果截圖

它有什么好處？

從諸多角度來講，Swift并不是一次徹底的顛覆。蘋果對某些特定設計模式青眼有加，他們也相繼推出了Objective-C與Cocoa來鼓勵開發(fā)者采用這些模式。Swift做的其實是同樣的工作，即進一步對此類設計模式加以規(guī)范、以扼止有所上揚的模式自由化趨勢（例如屬性）。Swift帶來的大多數(shù)特性在其它現(xiàn)有編程語言當中都能找到，因此不少開發(fā)者會在使用過程中產(chǎn)生熟悉之感。此次添加進來的新特性總體而言非常出色，同時被淘汰出去的機制（例如指針算法）也確實屬于困擾了開發(fā)者很長時間的大麻煩。

從這個意義上出發(fā)，Swift是一套優(yōu)秀的、以Objective-C為基礎的增量化升級方案。所有的顯著變化都體現(xiàn)在基本語法層面。使用分號與括號——或者干脆不使用，這都沒關系。將方法標記包含在函數(shù)調(diào)用當中也并無不可——只要大家愿意，一切皆有可能。通過這樣與那樣的實例，我們發(fā)現(xiàn)Swift確實是一款允許大家選擇自己最適語法及風格的出色編程語言，在很多情況下還能幫助我們將輸入內(nèi)容控制在最低范圍——還是那句話，只要我們愿意。

大部分新特性都已經(jīng)出現(xiàn)在其它語言當中，而語法的變化也將Swift逐漸擺脫了Objective-C的獨特性。我們通常都可以利用完全不同的語法編寫出同樣含義的代碼。這一切讓Swift破除與其它編程語言之間的障礙高墻，使之成為很多開發(fā)者熟悉且樂于接受的新型語言。這樣的設定非常重要，而且有利于蘋果吸引那些此前從未接觸過C語言的開發(fā)者加入到iOS應用開發(fā)陣營當中。當然，這些新入門的開發(fā)者仍然需要學習蘋果框架的設計模式，但至少他們不用再同時面對一套自己從未接觸過的編程語言了。

總體而言，以上因素非常積極、相信能夠帶來不錯的用戶反響。如果蘋果堅持選擇單一的編程風格，那么其中的一部分要求也許會與我們的開發(fā)習慣相去甚遠。然而在靈活性的支持下，我們?nèi)匀荒軌蛞苑浅＝咏陨硎熘姆绞竭M行開發(fā)工作。

不過這還并不是全部。Swift當中仍然存在著一部分我個人比較反感的特定語法，而且在某些情況下一個字符的謬誤就會將整行代碼的意義失之千里。綜合來看，語法的變動會讓由多位開發(fā)者負責的大型Swift開發(fā)項目在管理上更困難——至少比Objective-C項目更困難。

蘋果公司接下來要做什么？

很明顯，Swift目前還處于起步階段。這款編程語言降低了大部分常見失誤的發(fā)生機率，并徹底規(guī)避了某些糟糕實踐方式的出現(xiàn)可能性。如果大家愿意，完全可以在Swift中以非常簡潔的方式編寫代碼，這能夠大大降低開發(fā)者的工作壓力。它引入了多項優(yōu)秀的新特性，應該能夠幫助開發(fā)人員提高工作效率。這一切都是其積極的一面。

不過從宏觀角度看，蘋果決定也許會惹惱很多像我這樣的開發(fā)者。我花了很多時間來學習如何順暢使用自動釋放池，我的應用程序并不會導致內(nèi)存溢出，因此我覺得自己沒必要了解那么多語法來避免自動引用計數(shù)由于循環(huán)引用而最終無法被回收。我對于使用符號來訪問屬性沒啥興趣，因此我只在別無選擇的時候才使用符號。簡言之，我安于現(xiàn)狀、不喜歡被迫接受一種新的語言。

像我這樣的開發(fā)者群體直接導致運行時與編譯器團隊無法拿出優(yōu)秀的解決方案。如果每個人都能使用同一項功能特性，那么技術團隊可以輕松拋開傳統(tǒng)支持任務、轉(zhuǎn)而對目前仍處于活躍狀態(tài)的事物進行優(yōu)化。更小的內(nèi)存空間占用與更出色的性能表現(xiàn)意味著更低的組件成本與更理想的電池續(xù)航能力，這一切對于蘋果公司而言都是值得為之奮斗的目標。

蘋果承諾Swift會帶來更出色的性能表現(xiàn)，大家通過一些細節(jié)已經(jīng)可以看出點端倪。常數(shù)在Swift中所占的比重非常大，其意義也極為顯著。如果我們要制作一款股票追蹤應用，股票的價格當然每秒鐘都會發(fā)生變化，不過股票的名稱與對應符號卻很少變動，而且即使出現(xiàn)這種情況、我們也能夠輕松創(chuàng)建一個全新對象來應對。將股票的名稱與相關符號聲明為常量，這樣大家就不必以安全進程方式對其進行變更。根據(jù)我的推測，編譯器還能夠根據(jù)常量的使用情況作出進一步優(yōu)化。

一場巨大的變革即將出現(xiàn)，我們這些保守的頑固派應當清醒地認識到這一點。從現(xiàn)在開始的兩到三年之后，蘋果可能會宣布Swift才代表著未來并準備逐步放棄Objective-C，我們對這樣的消息不該感到驚訝。而且到那時我也不會對這一切感到懊惱，因為我已經(jīng)在這幾年中允許了解了這款新語言的使用方法。

原文：A Fast Look at Swift: Apple’s New Programming Language

核子可樂譯