毫無疑問，Swift 2.0在2015全球開發(fā)者大會（Worldwide Developers Conference, WWDC 2015）上被發(fā)布的消息眾人皆知。我會就該語言所發(fā)生的變化撰寫一系列的文章，但目前我們先說說重點。
現(xiàn)在全局函數(shù)和獨立（free-standing）函數(shù)都和方法一樣，遵循同一個參數(shù)標簽規(guī)則。不再使用＃這樣的語法來引用外部資源。
你基本上可以使用enum SomeEnum<T,U,V>來聲明multi-payload風格的枚舉，這樣就能正常運行。這用來提示未完成的指令寄存器（IR）引發(fā)的錯誤。
條件循環(huán)語句目前的語法是repeat { } while(cond)，不再使用do。
關鍵字do目前用來引入一個新的作用域（這對新引進的錯誤處理和 defer 關鍵字很重要）。在 C 語言中你可以用大括號，但 Swift 里就要理解為閉包（closure）。所以使用關鍵字do可以任意引入作用域。
guard語句塊顯式地聲明你要恒成立的條件語句，恒成立時跳過整個guard 語句。這樣做的好處是綁定在guard語句的變量在函數(shù)的其他部分也可用。這就避免了將所有的東西都圍繞一條if語句嵌套使用來解析（unwrap）可選類型的變量。執(zhí)行到函數(shù)中guard語句中的else部分，函數(shù)一定會退出并拋出異常。也可能會調用帶有@noreturn標記的函數(shù)。
文本注釋（doc comments）換成了Markdown格式，與Playgrounds統(tǒng)一（Playgrounds注釋格式源于功能有限的reStructured Text）。
編譯器對冗余的協(xié)議一致性，未被使用的綁定值以及可以設為常量的變量這些情況目前會給予警告或報錯。
Swift語言的調用約定更加智能，能夠理解 API 所發(fā)生的變化和 Swift 所給出的警告。并且還可以升級（但還不是那么完美，一定還漏掉了一些東西）。
find函數(shù)改名為indexOf，sort則變成了sortInPlace，sorted變成了sort。
String不再直接遵循序列類型（SequenceType），大概是為了避免一些新的可用協(xié)議擴展。目的是迫使你使用s.characters，s.utf8或s.utf16明確你想處理的unicode編碼。
允許對泛型添加公共擴展。
非泛型類類型可以繼承泛型類（強制類型參數(shù)固定）。
便利的可失敗構造器（failable initializer）可以先返回nil，而不必首先調用self.init。這是有利的一面，但指定了構造器在返回nil前仍要給所有字段初始化。所以此處還有改進的余地。
這解決了單元測試中的一個較大的難點。以前的做法：
Swift文件包含在test target中。現(xiàn)在不同的模塊中有重復的類的定義，出現(xiàn)無法將“X”轉換為“X”這樣非常可怕的錯誤，有時會無法執(zhí)行特定的測試。
在測試中引入引入主程序（main program）作為一個模塊。現(xiàn)在一切都聲明為public，所以對于測試來說都是可見的，有時候也包括應該聲明為private的內部細節(jié)。
現(xiàn)在可以啟用testability，它就像C＃中的InternalsVisibleTo。主應用程序目標模塊的內部細節(jié)對測試模塊可見。
在對應用或框架的測試設置中，啟用testability。
在單元測試中，使用@testable import {ModuleName}。
這將導致測試忽略某些優(yōu)化行為并保留稍后導入到測試模塊中的那些內部符號。官方文檔警告說，由于阻止了某些優(yōu)化，因此這只適用于調試和測試版本。
switch語句的模式匹配（pattern matching）語法和“if let ..., .... where”語法一直在推廣。可以在任何控制流中使用逗號操作符和where條件語句。還可以使用新的case條件語句，例如：if case .Silly(let a) { }。還有一種用于Optional<T>的特殊形式：if case let a? = anOptional { }。
模式匹配在循環(huán)語句中也可以使用：for case let thing? in array { }。
這又是值得單獨成文的另一個特性。
在關于Swift的文章里談論這個做甚？它的作用是使某些銜接更加清晰和簡便。不求在這篇文章中面面俱到，我會再單起一篇文章闡述它。
這不是我們一貫所認識的異常，這是一個使函數(shù)提前返回Result<T, Error>的操作，單隱藏了所有提前返回的對象，也隱藏了錯誤解析（error unwrapping）過程等內容。
[cpp] view plaincopy
let systemAttributes: [NSObject: AnyObject]?
do {
systemAttributes = try NSFileManager.defaultManager().attributesOfFileSystemForPath(documentDirectoryPath.last!)
} catch _ {
systemAttributes = nil
}
它完美地與Objective-C進行互操作，Swift語言中，將標記為throws的方法作為選擇器。這是使用NSError的方法，-(BOOL or nullable type)someMethodTakingParam:(type)param error:(NSError **)，這種樣式會自動引入標記為throws的方法。
應該明白的是這并不像Java中已經被檢查過的異常（checked exception）那樣。Swift語言并不關心異常的類型，或者處理或者不處理。這又是值得單獨成文的另一功能特性。
關鍵字defer也很重要，因為它可以取代傳統(tǒng)C風格的“if(err) goto cleanup”。獲得資源后接著就是defer { release_resource() }。然后不管函數(shù)返回結果如何，獲得的資源都將被清理。這也意味著資源的釋放緊隨獲取資源之后。這看起來不起眼兒，實則很重要。
位操作枚舉（bitwise enumeration）與數(shù)組風格的語法相結合，而不使用管道符“ | ”按位操作，并且具有所有范圍的集合操作功能。檢查一下是否具有contains功能的標志，或能夠執(zhí)行像isSubsetOf和isDisjointWith等這樣集合操作的其他功能。這是顯著的改進，表達了不直接對位進行操作的意愿。
這種變化意味著位操作枚舉實際上不再是枚舉了。將這些位操作枚舉聲明為結構體，實現(xiàn)OptionSetType協(xié)議，提供rawValue屬性。并且創(chuàng)建值作為結構體的靜態(tài)成員。Swift便會搞定其余的一切，自動提供所有集合的操作。這是我希望將來看到的更加明了的語法內容。
協(xié)議如今可以被擴展了，包括與類型約束有關的通用協(xié)議。還可以自己提供協(xié)議的默認實現(xiàn)。
先前，你不能你說：“我要使用方法X來擴展CollectionType，但只有集合中的類型滿足某些條件才可以”。現(xiàn)在，你可以這么做，并且很多像map，filter和sort這樣的全局函數(shù)已經進行了擴展。
這樣就解決了很多痛點，這也是值得單獨成文的內容。同時，要看看WWDC的面向協(xié)議編程（Protocol Oriented Programming）了解一些細節(jié)。
大量的API已經進一步進行了審計而更合理。舉幾個例子：
UITableView的dequeueReusableCellWithIdentifier方法現(xiàn)在返回UITableViewCell?類型的對象。
UIKit的屬性現(xiàn)在也被聲明為了實際的屬性。
用translatesAutoresizingMaskToConstraints = false代替了setTranslatesAutoresizingMaskToConstrains(false)。
@available屬性自Swift 1.2就存在了并且后續(xù)支持得很好。添加了一個新的陌生語法if#available()，為處理版本檢查提供了支持。而不是插入你喜歡的方法。
遺憾的是你不能只聲明一個屬性UISearchController并將target設置為iOS 7，然后只允許訪問類中的屬性。Swift希望整個類的定義都可以或者不可以。
也可以不再采用協(xié)議，除非支持target設置中所有的操作系統(tǒng)版本，除非將整個類標記為只在更新的操作系統(tǒng)版本可用。
這意味著使用if #available()存在單獨的子類和對創(chuàng)建適當對象的保護。
盡管如此，我個人還是發(fā)現(xiàn)了一個Bug，應用在iOS 4.0-4.1發(fā)生崩潰，由于編譯器沒有發(fā)出警告，方法只在iOS4.2才引入，因此我猶如與定時炸彈相伴。
Swift現(xiàn)在可以使用C函數(shù)指針，CFunctionPointer已不復存在。任何全局函數(shù)，嵌套函數(shù)和不捕獲狀態(tài)的閉包都可以作為一個C函數(shù)指針直接傳遞。你也可以調用來自C程序的函數(shù)。
你可以顯示地使用新屬性@convention(c)，表示函數(shù)應該使用C調用約定，簡單痛快！盡管我想不出在此對塊（block）的支持有何用，作為所發(fā)生變化的一部分，@objc_block也被刪掉了，使用@convention(block)取而代之。@convention(swift)默認支持所有函數(shù)和閉包。
這并不是編程語言所特有的。iOS 9含有不同版本的Swift標準庫，并且在未來系統(tǒng)中將添加修正后的Swift標準庫。結合新的App Thining技術，下載過程中蘋果商店會將Swift標準庫剝離出去的。我仍然在追根溯源地探求這究是如何工作的。
明顯的一個遺漏是處理異步代碼。
蘋果公司為我們提供了GCD，這是一個強大的基礎類庫，可以構建很多異步操作和并發(fā)原語。
然而，這些天我們做的每件事，構建用戶接口和API都需要考慮異步性和并發(fā)性。我們把一個文件讀操作鎖定一段時間，對用戶來說整個世界就都靜止了。
這是個持續(xù)的痛點，不是多大的事兒，但如果經常性地每天重復，恐怕也是不行的。
C＃和JavaScript都采用了async/await來為異步代碼提供一流的語言支持。我想很多人都想知道，Swift會提供什么樣的語法糖來幫助我們在實現(xiàn)異步操作方面確保正確性。我不知道在Swift 2.0發(fā)布的時間框架內是否會看到什么，但愿能有好的東西出現(xiàn)吧！
宣布的內容中，反響強烈的無疑是Swift開放源代碼。蘋果公司已經承諾在今年底前開放源碼，我們也沒有理由對此表示懷疑。與蘋果公司編譯器團隊成員討論過程中，他們看起來似乎對此由衷地興奮，無論如何堅決要干成這件事（我有點小失望，他們沒有打造出經典的蘋果然后宣布開源，但我仍然對此消息發(fā)自內心地感到高興）。
Swift 2.0有很多令人喜愛之處。蘋果公司的Swift團隊向大家承諾他們會迅速行動。到目前為止這些承諾已經被兌現(xiàn)。成為蘋果平臺上的開發(fā)人員是一個激動人心的時刻。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業(yè)目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
