我们期待的 Swift 3.0 将会是什么样? —— 此调查来自官方的 Swift 社区

本文主要翻译自苹果文档, 但不和原文完全一致.苹果原文连接

2015年6月,一年一度的苹果 WWDC 大会如期而至,在大会上苹果发布了 Swift
2.0,引入了很多新的特性,以帮助开发者更快、更简单地构建应用。本篇文章作者是
Maxime defauw ,本文中 Maxime 向大家简要介绍 Swift 2.0
中值得注意的新特性。本文系 OneAPM 工程师编译整理。

随着诸如协议扩展、错误处理等 Swift 2.0
新引入的强大特性发布,这都意味着苹果已经明确表示,它们非常积极地听取来自开发者社区的意见来帮助完善和改进这门语言。我们调查了几位使用
Swift 的开发者朋友,询问他们对下一个版本的 Swift
有何希冀,因此他们将在类型系统、协议以及工具等方面和我们一起分享他们的想法。

图片 1Swift
2.0

一年前,苹果推出了面向 iOS 和 OS X 的全新编程语言——
Swift。当听到它发布的时候,像千千万万 iOS
开发者那样,笔者的内心激动无比。正如宣传所说的那样,作为一门快速、安全的编程语言,Swift
已经成长为最流行的编程语言之一。一年之后,苹果不负众望,在2015年的 WWDC
会议中推出了 Swift 2.0。作者有幸去了现场,所以在这里向大家介绍一下 Swift
2.0 的新特性。

Sash Zats 

Labgoo、Wondermall 的
iOS 工程师、用户体验设计师及 API 架构师

Swift 2.0 改进很大, 尤其是在现代化, 强大, 表达力, 易用性方面. 相比 Swift
1.2的新的特性有:

「今年,我们将借助 Swift 2.0 乘风破浪。我们认为 Swift
即将成为最大的编程语言,并且成为下个二十年最不可或缺的应用和系统编程语言。任何人在任何地方都能使用
Swift 」,苹果公司软件工程副总裁 Craig Federighi 说道。

类型化的错误

我第一个期望就是类型化的错误(typed
error),虽然这个想法还很不成熟,但是却能给错误处理带来极大地改善。Swift
2
 引入了新的错误处理机制,但是遗憾的是,和语言中其他结构不同,错误结构并不是类型安全的。这样做的好处就是错误处理成为了函数签名(function
 signature)的一部分,比如说 do something()
do something() throws的类型并不相同,前者无法代替后者来使用;坏处就是
dosomething() throws
无法指明它能够抛出的错误类型(就像协议列表一样:throws<IOTypes, NetworkingError>)。

  • 错误处理 现在Swift开始使用throw, catch来处理errors,
    也就是高级语言中常见的异常处理机制, OC, Java, C#, C++等早已实现.
    Swift 2.0 的错误处理机制和原有的NSError错误处理方式保持了无缝衔接.
  • 版本可用性检查 版本可用性
    帮助开发者检查API在要发布的OS版本上是否可用.
    假设你的发布目标是支持iOS7及以后的系统,
    如果代码中使用了一个iOS8中才有的方法, 在编译时,
    现在Xcode就会提示错误.
    另外也可以标记开发者自己写的方法在哪个版本的OS上可用.以前要达到类似的目的,
    开发者需要自己去判断系统版本, 判断API在某个版本的iOS上是否可用,
    现在苹果给出了官方解决方案.
  • 可测试性 有了可测试性, 在单元测试的时候,
    可以在测试中调用非公有的方法.
  • 协议扩展 协议现在可以通过扩展增加方法和属性,
    以前只有类和结构体可以扩展.
  • Swift 1.2 to 2.0 迁移Xcode7 可以协助将Swift
    1.2的代码高效的迁移到Swift 2.0,
    包括projects和playgrounds的代码.图片 2Swift代码迁移

图片 3Swift 2.0 到底「新」在哪?

依赖类型

我的第二个期望是提供“依赖类型”(dependent
type)的支持。这个想法同样仍未完全在我的脑海中成型,不过我确信它将给现有的类型系统中带来全新的绝妙体验!它将给值类型本身加入限制,类型系统的解析方式为:未定类型的数组
-> 字符串数组 ->
只含有2个元素的字符串数组
。这对现有语言来说是一个极其有用的补充。下面的例子阐述了这个功能在什么地方比较有用:

class Car {
  var wheels: [Wheel]<4> = [Wheel(), Wheel()] 
  // 编译错误,类型不匹配,需要 4 个Wheel 类型
}

详情参见: The Swift Programming Language

在 WWDC
大会上,苹果测量了分贝的新功能普及性。会议中两次最大的掌声,一次是苹果宣布
Xcode 7 支持 UI 测试,另一次则是 Swift 的开源。如果你错过 WWDC
的主题演讲,或者最近生活得压力山大,那么请你再确认一下,你没有看错:Swift
真的开源了。这可是件大事!下半年,苹果还将公开发布在 OSI 标准许可下的
Swift 的源代码,包括编译器和标准库。苹果也将开放 Linux
的源代码端口,开发者将能够促进语言的发展,并在 Linux 上编写 Swift
程序。由此看出,苹果鼓励开发者进一步推动 Swift 的发展。

Cocoa 的 Swift 分支

最后,我希望看到(不过很可能不会实现)Cocoa 的 Swift 分支版本。虽然
Cocoa
是一个很棒的框架集合,但是它自身携带的内容实在过于庞大,有可能会影响到
Swift 的开发方式。

我很想看到无需进行引用的结构体能够普遍应用到新的分支上来(在我的想象中,我认为诸如
 UIBarButtonItem、UINavigationItem
 之类的类应该不需要让你来累积它们的状态,因此它们可以被替换为结构体)。因此,我们就可以重新设计
 API,尽可能地使用枚举中关联值的优势。在某些情况下,枚举能够更精确地描述其作用:例如
UIDatePicker
 可以在一个属性中使用关联枚举,来同时表示其日期值和创建值所使用的模式。

class UIDatePicker {
  enum Value {
    case Date(date: NSDate)
    case CountDownTimer(period: NSTimeInterval)
  }
  var value: Value?
}

虽然这不大可能会发生,因为这种变化需要一个独立的团队为现有和新的 API
建立一个全新的版本,这个过程中需要耗费极大的努力。

我知道,我的这些想法和 Swift
团队正面临的实际问题和长期目标而言是非常的幼稚的,因为整个社区都知道他们所做的一切棒极了!

为了能够和Swift无缝的高效的结合, Objective-C进行了更新. 最新的特征包括:

随着这一令人振奋的消息的发布,Swift 2.0
涵盖了更多新的功能,如升级的错误处理、协议扩展和可用性检查。下面我们就来看看这些新特性。

Jorge Ortiz

PoWWaU 创始人,移动开发开发者及教师

  • 泛型 因为Swift中集合的元素都是有类型的, 为了和Swift更好的兼容,
    新版本里, OC开始支持泛型, 主要是在各种集合类型(比如数组, 集合,
    字典)中使用.
  • 可空性标注 因为Swift的代码里面的主要类型默认是没有空值一说的,
    只有可选类型才可以为空. 为了和Swift更好的结合, Objective-C中也加入了
    可空性标注 , 可以标注是否期望一个值是否可空.
  • Kind-Of. 通过使用 __kindof 声明某对象是某种类型,
    让编译器知道对象是某种类型或者该类型的子类, 可以用在泛型参数里. 使用
    __kindof 对类型进行约束, 比指定某种类型或者id类型更灵活一些.

程序总会出错。当函数出现问题时,如果能找出哪里出错,便能理解为什么会出现异常。Swift
1.0 版本缺乏有效的错误处理机制。在 Swift 2.0 中,开发者可以利用 try /
throw / catch 关键字,建立异常处理模式。

更好的辅助工具

我希望有一套比较成熟的辅助工具。比如说,我希望有一个我可以永远信赖的调试器,而不是时不时出错的玩意儿。这个调试器能够在当前的堆栈帧显示某个
符号的实际值。此外,我还希望有一个能够对 Swift 进行重构的编辑器,就像在
Objective-C
中所做的那样,这样我就可以在它的帮助下改善我的代码,比如说将一些语句提取到方法中,或者重命名项目中某个类或方法的名称。

这个编辑器需要能够生成代码,将我从代码套路中拯救出来(我的意思不是指代码片段)。例如,如果编译器发现我的类或者结构没有完全实现某个协议,那么我希望有一个选项能够让编辑器自动将定义中所缺少的方法创建出来。

详情参见: Using Swift with Cocoa and Objective-C

假设你正在加入汽车引擎模型。引擎可能由于某些原因导致失败:

完善的测试

第二个愿望非常简单,但是却能够让进行测试的人们感到由衷的高兴。我希望运行测试时无需使用模拟器,这样能够提升使用体验。如果某个类只基于
Foundation,那么对其的测试应该可以无需模拟器就可以进行。这将减少需要运行的测试套件,使测试花费的时间更短。

图片 4操场Xcode6中引入的
操场 , 是一个探索和实验Swift代码的好地方. 在Swift 2.0里,
你可以使用操场来协助解释怎么使用一个API, 或者示范一个概念.

  • 没油;
  • 漏油;
  • 低电量。

内省机制

第三个愿望就涉及到语言本身了。我希望 Swift
拥有更好的内省(Introspection)能力,如果你愿意的话也可以称之为反射(reflection)。此外,还希望其拥有更加动态化的调度机
制。没有了这些特性,诸如 Mocking 框架之类的工具将无法被创建出来。

  • 操场写作 Swift代码里现在允许使用mardown来创建富文本的注释,
    更多参见: Playground Reference
  • 行内结果 以前每行代码的执行结果显示在timeline区域,
    现在可以把结果的显示移动到该行代码的下面, 这样看起来会更清晰.
    行内结果结果的可配置性比在timeline区域更好.
  • 资源 现在可以方便的把图片, 音频等资源方便的加入到操场中使用.
  • 辅助源码 辅助源码功能, 可以让你吧一些辅助的代码从操场中移出去.
    这样操场里的信息看起来就更清晰了.
    另外辅助源码会处于被编译完成的状态, 实时解释的只有操场中的代码,
    这样运行起来会快很多.
  • 操场分页 在Xcode7里面, 可以在一个操场里面包含多个页面,
    这样方便你把相关的概念绑到一起.

在 Swift 中,错误可以看做符合 ErrorType
协议的类型值。在这种情况下,你可以创建立一个符合 ErrorType
的枚举模型来表示错误情形:

Sam Giddins

UChicago 2018. CocoaPods. Bundler.

详情参见: Playground Help

enum CarEngineErrors: ErrorType { case NoFuel case OilLeak case LowBattery}

高阶泛型类型

首先我需要向大家道个歉,因为你可能会很反感我们这些骄傲的开发者需要向
Swift 团队乞求我们所希望的 Swift 3
新特性。不过我觉得实现这个特性是最为重要的,因此无论怎样我都在所不辞。

由于高阶泛型类型(High-Kinded
Type)是一个难以理解的东西,因此我打算用我们最喜欢的函数式编程比喻——卷饼,来为大家解释。我们知道,我们可以用同样的方式吃各种各样的卷饼,无
论里面的内容如何,因为卷饼本身只是内部填充物的一个包装而已。但是,如果我们有这样一个方法告诉
Swift,“这里是一个对象,我唯一关心的事情只是它是一个卷饼,无论里面卷了牛排还是蔬菜还是虾,我都只关心它是一个卷饼。”然而
Swift
并不能让你轻易做到,如果你要吃某个卷饼的话,你首先需要这么做:“拥有相同填充物的卷饼是相同的”。这样的话,你会发现你能使用的卷饼为数甚少……

我们勉为其难地说目前 Swift
的上层结构类型并不能让我们这样表示。并没有任何办法写出关于 Monad 或者
Functor
的定义,这些定义可以用在该类型的所有实例当中,举个例子,这意味着我们所添加的每个全新的
SequenceType,都必须表示为 S: Equatable when S.Element: Equatable
的形式。这让代码重复量十分可怕,这意味着我们不能将我们的真实目的编码到类型系统中,导致我们程序员有更多犯错和制造
bug 的情况发生。

Xcode 7现在可以开发多达3个平台(我理解是指手表, iphone, ipad三个,
不包括mac电脑)上的应用, 设备种类也很多.
不同的设备其容量和屏幕分辨率等规格各不相同. 针对同一个APP, 利用Xcode7和
iTunes App Store, 你可以为每种设备进行优化, 该设备上用不到的图片等资源,
就不下载到设备上.

构造一个可以抛出异常的函数,在声明中使用 throws 关键字,如下例所示:

Jacob Schwartz

Glint 首席工程师

  • Bitcode在应用打包传到App Store的时候,
    Xcode会把应用编译成一种中间代码bitcode(不是二进制的可执行代码). App
    Store会按照需要将bitecode编译成64位或者32位的可执行代码.
  • 切片 放在AssetCatalog里的图片, 可以通过打上标签,
    让不同的设备在下载app的时候, 选择该设备需要的图片.
  • 按需资源 在app下载安装完成之后, app store可以存储一些额外的资源.
    这些资源可以打上标签, 按照一定的策略和控制进行下载.
func checkEngine() throws {}

取消 Xcode 和 Swift 版本的关联

我很高兴能够看到 Swift
语言演变至今,我认为它的团队正在做一个十分了不起的工作,并且他们能预测到我们的需要,并且对大众反馈做出反应。

对于 Swift 3.0 来说,我很希望能够从不同版本的 Xcode
中使用这门语言。我并没能够完全深入地研究 Swift 2.0,因为它只能够在 Xcode
7上面使用,而 Xcode 7 取消了支持 iOS7 。将 Xcode(以及 iOS SDK)和 Swift
版本关联起来会造成不必要的惰性,阻碍开发者们迁移到新的语法当中。

所以不要让我们难以取舍,让我们在任何时候都能够用上最新的语言!

详情参见: On-Demand Resources Guide

详情参见: App Thinning (iOS, watchOS)in the App Distribution Guide for
detailed information.

函数中抛出错误,你可以使用 throw
声明。下例代码演示了如何对引擎错误进行简单检查:

Viktor Belenyesi

Prezi 首席 iOS/Mac 开发者

为了帮助开发者开发出更好的app, Xcode 7 增加了新的调试和程序分析特性

let fuelReserve = 20.0let oilOk = truelet batteryReserve = 0.0 func checkEngine() throws { guard fuelReserve > 0.0 else { throw CarEngineErrors.NoFuel } guard oilOk else { throw CarEngineErrors.OilLeak } guard batteryReserve > 0.0 else { throw CarEngineErrors.LowBattery }}

扩展中的存储属性

就像 Scala
的特性一样,如果我们能够给既有类中通过扩展添加新的存储属性的话,这将会是巨大的改进。我们可以用
ObjC
运行时来实现此功能,但是这种代码给我的感觉很不好,因为我每次都必须输入这样的鬼东西:

extension UIView {
  var myTag: String? {
    get {
      return objc_getAssociatedObject(self, "myTag") as? String
    }
    set(newValue) {
      objc_setAssociatedObject(self, "myTag", newValue, UInt(OBJC_ASSOCIATION_RETAIN))
    }
  }
}
  • iOS电量仪器Xcode 7 提供了电量仪器, 帮助你测量你的iOS app
    使用的电量. iOS 9 加入了基于每个进程跟踪电量的能力,
    可以生成电量报表. 这是一种检测你的app对电量影响的很棒的方法.
    你可以看到app的异常行为,
    例如在你的app本该空闲的时候出现了大量的电量消耗.

guard 关键词是 Swift 2.0 为了增强控制流首次引用的。当执行到 guard
语句时,首先会检查条件语句。如果条件为 false,则 else
部分会被执行。以上代码中,如果没有条件符合,函数将会抛出异常。

Agnes Vasarhelyi

Prezi iOS/Mac 开发者

详情参见: Energy Efficiency Guide for iOS Apps.

为了调用抛出函数,需要把 try 关键字放在函数调用之前。

自定义泛型类型中的协变机制

Swift 中内置的类型已经是协变(covariant)的了,但是当涉及到自己创建的
Party
的时候,一般情况下就必须要给来宾名单中加入不同的人,不然的话这个设计就是失败的。

图片 5

在app运行的时候, 调试测量仪器和他们的报告提供了一种快捷的视图.
如果需要更详细的信息,
每份报告都提供一个方式来启动Instruments来加载你的app.
Instruments的界面重新进行了设计,界面交互变得更简单, 更自然.
比如加入了捏合缩放手势, 让在数据间导航更顺畅.

func startEngine() { try checkEngine()}

Sam Ritchie

CodeSplice首席Codesplicer

详情参见: Instruments User Guide.

如果在 Playgrounds 中写入以上代码,在处理异常之前已经出现错误。Swift
里的错误处理机制,需要使用 do-catch 语句来抓取异常并进行恰当处理。

约束泛型的协议一致性

Swift 扩展有两个非常有用的功能,一个是能够增加协议的一致性(protocol
conformance),比如说在 Swift 1 中:

extension String: JSONEncodable {
  func toJSON() -> JSON { return .String(self)
   }}

另一个就是能够给协议增加泛型约束(generic constraints),比如说在 Swift 2
中:

extension Array where Element: JSONEncodable {
  func toJSON() -> JSON {
    return .Array(self.map { $0.toJSON() })
  }
}

很遗憾的是,你不能将这两者结合起来(即给约束泛型类型添加协议一致性),比如说:extension Array: JSONEncodable where Element: JSONEncodable
这种写法是无法通过编译的。这意味着如果你在尝试使用“面向协议编程”的话,你不仅需要避免使用泛型,还要花费大量的时间和精力来写重载函数。如果这项特性能够在
Swift 3 中实现的话,那么我相信它能拯救很多代码,让协议以及泛型更加有用。

  • 地址消毒剂 Xcode7能够在编译应用时加入地址消毒剂,
    用以帮助捕获和调试内存冲突. 堆栈缓冲溢出,
    野指针等内存冲突导致的崩溃Objective-C和C代码很容易产生.
    内存问题可能导致app崩溃, 也可能让app发生诡异的行为. 由于难以复现,
    并且bug现象和源头可能相距很远(比如登陆功能有野指针可能导致商品的名称显示不正常),
    内存问题很难追踪.在build scheme里面启用地址消毒剂,
    你就可以在发生问题的时候定位内存地址.
    Xcode同时也会提供诸如地址和对象的关系, 对象分配和回收的信息,
    从而帮助你定位和解决为题. 地址消毒剂的性能很好.
    支持模拟器和真实设备, 支持iOS和 OS X.

下面的函数指定了捕获异常后的响应:

Tony Arnold

Itty Bitty Apps 以及 The
CocoaBots 的首席开发者

我对语言本身其实没有太大的期望,不过如果能有类似 C#
之类的语言的异步风格函数(Async-Style
Function)的话,那就再好不过了。不过我最想看到的还是更好的辅助工具。在
Xcode 中使用 Swift
仍然是一件很痛苦的事情,比如说我无法使用重构,这让我感觉好像在使用几十年前的
IDE一般。如果能有更好的工具,并且有更清晰的错误提示的话,那无疑再好不过了。

同样我希望在明确需要使用 Optional.None
的地方让nil被禁用掉,不过这听起来像是我喝多了才会提出这个建议的。

说句实话,我并没有实实在在地思考过 Swift 3.0
的模样。标准库就已经很好很简洁了,如果它缺少什么东西的话,你实际上可以自己搭建出来。

Xcode 7里面, XCTest框架加入了一个主打的特性: UI testing. UI
testing以XCTest现存的API和概念的一个扩展的方式实现,
已经熟悉Xcode的测试功能的开发者很容易上手.

func startEngine() { do { try checkEngine() print("Engine started", appendNewline: true) } catch CarEngineErrors.NoFuel { print("No Fuel!") } catch CarEngineErrors.OilLeak { print("Oil Leak!") } catch CarEngineErrors.LowBattery { print("Low Battery!") } catch { // Default print("Unknown reason!") }}

Benji Encz

Make School 工程师,即将入职
PlanGrid

  • UI 录制 UI test方法可以通过录制UI交互操作的方式创建.
    当用户和应用交互的时候, Xcode在你的测试方法里面注入代码,
    这些代码找到你app的UI元素, 访问他们的属性, 调用他们的事件.
  • 正确性和性能 XCTest现在为定位UI元素, 访问元素的属性,
    调用事件提供了丰富的特性. 在UITest中, assert, 性能监视等同样支持.
  • 代码覆盖率在scheme里启用代码覆盖率功能,
    就可以对代码覆盖率进行可视化.
    在测试报告里可以看到哪个文件里的哪个函数的哪行代码是执行了还是没执行.代码编辑器也可以显示代码的覆盖率信息,
    让你看到在一此测试中哪行代码执行了, 哪行代码没执行.
  • Xcode Server. Xcode的测试功能已经和Xcode Server完整的集成.
    在Xcode Server上你在一个hands-off(放手,
    类似于骑自行车大撒把)的环境里, 在多个设备上执行测试, 反复的执行,
    统一和更好的评估app的正确性和性能. 新的Xcode Server
    报表格式会显示一个项目中的趋势, 回归反复进行的测试.

每个 catch
从句都匹配特定的错误,并且指定相关错误的响应机制。在上面的例子中,batteryReserve
变量被置为0,这种情况下调用 startEngine()将会抛出 .LowBattery 异常。

类型化的错误处理

我最想看到的就是函数可以抛出他们能够产生的错误类型。目前苹果的建议是在函数的文档中写出这些错误类型,但是如果编译器也知晓这些错误类型的话那是不是
更好一些呢?这样就可以实现一个精确的错误处理,而不是使用一个 catch-all
的错误捕获。这同样可以让 API 中可产生错误的函数能更好地表述自己。

详情参见: Testing with Xcode

假如把 batteryReserve 重置为 1.0,这样就没有异常抛出,窗口打印「Engine
started」的提示信息。

那么,你期望中的 Swift 3.0 是什么样子的呢?

转载自 realm.io

  • 在你自己的设备上开发在Xcode7里面,
    不再需要购买开发者以及进行繁琐的设置,
    你就可以在任意的设备上进行开发和调试了. 只需要注册一个Apple Id.

类似于 switch 语句,Swift 2
的错误处理机制是完备的,你需要考虑到所有可能的错误情况。所以我们需要包含一个不指定类型的
catch 从句。

详情参见: Launching Your App on Devices

如果需要了解更多 Swift 的错误处理机制,推荐大家参考 Apple
Documentation。

之前的Xcode为iOS和watchOS提供了分析和使用crash数据的方法. 现在, Xcode
7里面, OS X app也支持这个功能了.

在作者写这篇介绍时,他注意到 println()函数的缺席。在 Swift 2.0
中,我们只需 print()函数便能打印到输出窗口。苹果公司将 println()和
print()函数合二为一。如果你想隔行输出,可以将 appendNewline 参数设为
true。如下面代码所示:

  • Test Flight.Test Flight支持
  • 崩溃报告Xcode 7提供了更好的查看和使用崩溃报告的功能.
print("Engine started", appendNewline: true)

详情参见: Analyzing Crash Reports

在老版 Swift 中,你可以使用扩展为现有的类、结构或枚举添加新功能。Swift
2.0
允许开发者应用扩展到协议类型。随着协议的扩展,你可以通过添加一个特定协议,为所有类添加函数或属性,也便于扩展协议的功能。

如下例所示,创建一个新协议并命名为
Awesome。该协议可以由任何能返回特定对象的 awesomeness
指数百分比的类型来实现。

protocol Awesome { func awesomenessPercentage() -> Float}

现在声明两个遵守新协议的类。每个类都实现了 Awesome 协议的指定方法:

class Dog: Awesome { var age: Int! func awesomenessPercentage() -> Float { return 0.85 }} class Cat: Awesome { var age: Int! func awesomenessPercentage() -> Float { return 0.45 }} let dog = Dog()dog.awesomenessPercentage() let cat = Cat()cat.awesomenessPercentage()

在 Playground 中初始化该类并调用
awesomenessPercentage()方法,会看到如下输出:

图片 6Swift 2.0 到底「新」在哪?

如果你想补充一个 awesomenessIndex 属性来扩展 Awesom 协议,那么可以使用
awesomenessPercentage 方法的结果来计算 awesomeness 值。编码如下:

extension Awesome { var awesomenessIndex: Int { get { return Int(awesomenessPercentage } }}

在协议中创建扩展,所有遵循 Awesome 协议的类都能访问 awesomenessIndex
属性。

图片 7Swift 2.0 到底「新」在哪?

的确很炫酷,是吧?

开发者都知道,构建应用需要时时与不同 iOS
版本做斗争。你总是希望使用最新版的 API,但有时应用旧版本的 iOS
上运行时容易出错,这可能会导致 Bug。在 Swift 2.0
之前,没有标准方式来进行可用性检查。比如:NSURLQueryItem 类在 iOS 8
上才可用,如果在 iOS
以前的版本中使用则会出错,甚至会导致应用崩溃。为了避免这种错误,你可以按照以下代码执行可用性检查:

if NSClassFromString("NSURLQueryItem") != nil { // iOS 8 or up} else{ // Earlier iOS versions}

这是检查类是否存在的一种方式。从 Swift 2 开始支持 API
在不同版本下的可用性检查。你可以简单定义一个可用性条件,所以相应的代码块只能在特定的
iOS 版本下执行,举例如下:

if #available { // iOS 8 or up let queryItem = NSURLQueryItem() } else { // Earlier iOS versions }

经典的 do-while 循环现改名为 repeat-while,请参考下例:

var i = 0repeat { i++ print} while i < 10

希望大家能喜欢这篇关于 Swift 2.0 的介绍。还有很多内容没有涵盖到,比如
Markdown 格式的注释等。更多详情可以参考 this WWDC
video。写到这儿,很多公司还在使用 Objective-C 作为构建 iOS
应用的主要编程语言,很可能你也是。但作者仍坚信 Swift
的发展前景更为广阔。事实上,2015年 WWDC上所有重要会议都在使用
Swift,如果你还没有学习 Swift,是时候采取行动了!

你可以在此下载本篇文章的 Playground 文件。确保使用 Xcode
7运行的代码,这是唯一支持 Swift 2.0 的 Xcode 版本。Xcode 7
目前仍处于测试阶段。你可以从苹果官网上下载。

原文地址:What’s New in Swift 2.0: A Brief Introduction

OneAPM 是应用性能管理领域的新兴领军企业。Mobile Insight
能以用户真实使用感受为度量标准,检测每次崩溃的发生,协助监控移动应用性能。想阅读更多技术文章,请访问
OneAPM 官方博客。