Swift 的最新进展

（你好 WWDC 2020） 你好 欢迎来到 WWDC （Swift 的创新） 你好 我是 Ted 欢迎观看“Swift 的创新” （Ted Kremenek，语言及运行时） （Kyle Macomber，Swift 标准资料库） 如今 围绕着 Swift 的生态系统 正朝着多个方向成功发展 （Apple OS 及 API 中的 Swift） 在 Swift 5 中 对于 API 稳定性的引入 为 Swift 带来了二进制框架 也导致了新的强劲 API 的出现 比如 SwiftUI 作为 Apple Developer 体验的 前锋和核心 在过去的一年中 我们在 Swift 上投费了许多精力 不仅是在表面上 也包括后台 这些投费的精力增强了 Swift 对 Apple API 和其控制系统核心 以及 Apple Developer 生态系统的影响

（源代码开放式资源库） API拥有着不断扩充的 强大的源代码开放式资源库 而它完全受益于 Swift app 开发者在 Xcode 中 可以通过 Swift Package Manager 轻松便捷地进入并使用这个资源库

最后 Swift 作为一个跨平台的语言 解决了许多领域的问题 它持续不断地成长发展 并为远超以往数量的平台提供支持 对比最近两次 Swift 的发布 可以发现 其在性能表现、语言改进及开发者体验上 都有了持续性的改进 （今日包含的 Swift 发布内容） （Xcode 11.4— Xcode 12（预览） Swift 5.2— Swift 5.3） 让我们从一些 Swift 的运行时性能的 突出优势开始看起 （代码大小） 第一样要看的东西就是代码大小 代码大小是 app 的一部分 代表着 app 逻辑的机器代码表现 到目前为止的好几次发布中 这都是关于优化的核心关注点 （内部基准：二进制大小） 为了追踪过程 我们用 Swift 改写了 承载 iOS 系统的 app 中的一个 我们对 Swift 版本的 app 的代码大小 进行了追踪 并与 Swift 4 以来的 Objective-C 版本 进行了对比

我们从 Swift 版本开始 其代码大小是 Objective-C 版本的 2.3 倍

Swift 4.1 中所占的大部分 都用来优化代码大小的优化设置

在之后的每次发布 我们都缩小了版本之间的差异 到 Swift5.3 时 我们已经将 代码大小缩小到了 Objective-C 版本的1.5 倍 请注意 这其中的某些差异 是不可避免的 因为 Swift 的安全特性 在 app 的执行中占了一定的代码大小 然而 不同类型的 app 会产生 不同的二进制大小 这个 app 是一个 UIKit app 但 SwiftUI app 又是如何呢？ （减少43%） 在 Swift5.3 中 有着对于 SwiftUI app 代码大小的 重要改进 这是 MovieSwiftUI 它是一个极佳的源代码开放式资源 app 由 Thomas Ricouard 开发 我们可以看到它的 app 逻辑代码大小锐减了 40% 二进制大小对于像是下载次数之类的 东西来说是重要的 但是当你正在运行 app 时 它就是我们所谓的清洁内存 这个内存可以被清除 因为它可以在被需要时重新加载 所以它比脏内存更不具有决定性 脏内存就是 app 在运行时 分配和处理的内存 接下来让我们一起看一看 脏内存的使用是如何被显著改善的 （-脏内存 -内存布局示例） Swift 对于值类型的使用 在以参照类型为基础的语言上 有着一些基本优势 为了让大家理解为什么 我来举一个例子 这是一个在 Objective-C 中有着 UUID 字符串和序号的简单模型类型 让我们来看 当我们将它储存在数组中 这个模型是如何在内存中被保存的

在 Objective-C 中 对象变量只是指针 所以数组在模型类型中保存了指针

相应地 这些对象在它们的性能中 保存了指针 你所分配的每一个对象都有一些额外开销 性能表现以及内存使用量 Objective-C 对极小的 ASCII 字符串有 一串特别小的字符串表示是很重要的 因为它允许字符串被储存在指针内 而这也为指定额外的对象留出了余地

现在 我们将看一看 Swift 中的同一模型 Swift 对于值类型的使用 避免了这些值中的许多值 通过指针而被访问的需求 因此 UUID 可以在山对象中被储存 并且 Swift 的小字符串 可以保存更多的字符 最多可以达到 15 个代码单元 且包括了非 ASCII 字符

最后 所有的山对象 都可以直接在数组存储中被分配 所以 除了几个字符串除外 其余所有东西都被保存在 一个连续的内存块中 Swift 程序可以通过 使用像这样的值类型中 获得显著的内存益处 （20KB Swift 5.1—35KB Objective-C） 如果我们检测一组使用了 400 个 这类模型对象的堆内存的话 我们可以看到 Swift 模型数据更加紧凑 其大约是 20 KB 而不是 35 KB 注意这些测量值是来自于 Swift 5.1 的

（堆内存） 除了这个优点 一些 Swift 程序由于运行时额外开销 在之前仍然使用更多的堆内存 在之前的最初阶段 Swift 创造了 一些缓存和内存 这些缓存用来储存 例如协议符合 以及其它的类型信息 以及用于连接 类型与 Objective-C 的数据

所有的语言运行时都存在一些额外开销 但是在 Swift 的案例中 这个开销太大了 于是 这也是我们着重于优化的一点

我很高兴地告诉大家 在 Swift 5.3 中 我们已经极大地削减了这个额外开销 让 Swift 版本的 app 现在只使用 比去年发布时的三分之一还少的堆内存 为了获取这些改进的完整优点 app 的最小适配目标 需要被设定为 iOS 14 但是许多这些改进仍然可以让 适配于早前 OS 发布版本的 app 受益 （在用户空间堆栈中 减少 Swift 运行时） 在大多数的 app 中 这些差别并不是很能引起人们的注意 但是像这样优化 Swift 的内存 是决定性的 它允许我们在 Apple 系统中 将 Swift 进一步推进 使得在被使用的每个内存字节 都计算在内的 守护进程和低级框架中 可以使用 Swift （Swift 在系统堆栈 少于在 Foundation 框架） 为了达到这个目的 我们还做出了另一个重要的改变 我们调动了 Swift 的标准资料库 使它在堆栈中处于 Foundation 框架之下 这意味着它可以在真正意义上 被用于执行 浮于 Objective-C 标准之下的框架 而其之前则必须使用 C 语言 接下来 让我们将我们的注意力转向 如何继续改善开发者体验 （诊断） 我们先来看一看 编译器中的诊断、误差以及警告 是如何在这次发布中极大地被改善 （Swift 编译器中的新诊断子系统） Swift 编译器包含了一个新的诊断策略 以带来更精准的误差诊断 可以指出源代码中发生问题的准确定位 我们对于诊断问题的原因 有一些新的尝试 它们会生成可解决错误信息 并附带如何解决问题的指南

这里是一个无法理解的诊断例子 这个情况会在 Swift 5.1 编译器 一年前的 SwiftUI 代码上发生

而如今 这个诊断已经得到明显优化 错误信息会准确地告诉你问题在哪里 当诊断问题时 编译器内部也会记录更多关于问题的信息 它现在还会产生一些额外的备忘信息 这些备忘信息可以在多种情况下 帮助到开发者 使其能够更好的理解并解决问题 在这个案例中 使用 fix-it 自然而然地引导开发者 向文本字段的不完整赋初值 提供缺失的部分 （Swift - 新的诊断架构总览） 如果你对于在编译器中寻找更多 关于新的诊断架构的信息感兴趣 那么你可以浏览 Swift.org 并在博客中找到很棒的文章 （代码补全） Swift 的代码补全功能 在这次的发布中 也极大地被改善 从由编译器和 SourceKit 提供的 代码补全推论 到 Xcode 中的代码编辑器体验 让我们将注意力 转向补全结果是如何从根本上得到改善的 （改进类型 - 检查推论） 首先 候选补全的推论 得到了显著地完善 这里 当编译器在一个不完整的 代码字典字面量中被使用时 它正以三元的表达形式推论这个值 而这在之前不会就奏效

代码补全还提供给你所期待的值 一些语言上的 更加动态的功能 比如 将 KeyPath 用作函数 （对比 Xcode 11.5 代码补全速度改善） 除了补全结果的质量 代码补全的性能也得到了彻底地改善 在一些案例中 相较于 Xcode 11.5 新版本代码补全速度高达其 15 倍 （SwiftUI 代码中的代码补全性能） 这对于编辑 SwiftUI 代码来说 是尤为有益的 这些条形图展示了 在 SwiftUI 代码中以秒计量的 代码补全的普遍使用性能表现 在 Xcode 11.5 中 这些动作 将花费半秒来完成 比较容易注意到 现在 这些动作可在十分之一秒内被完成 （开发者体验—代码缩进） 在 Xcode 中 由源代码开放资源 SourceKit 供能的 代码缩进有了显著增强 （改善的缩进格式化） 你将会看到对于链式方法调用 及属性访问的改良后处理 而属性访问则是 Swift UI 代码中的主要组件 你还可以找到对于调用参数校准 元组元素、跨越多行集合元素 以及多行控制流的改进

在这里你可以看到产品其中一项改进 取自在 SwiftUI 中 源代码开放的 MovieSwiftUI 项目 之前 你有时会因为一些链式通道 而执行一个自然缩进

但现在 它们在视觉上都整齐地对齐了 这些以及其它我提到的改进 都将对你的编码体验造成显著的影响 接下来 让我们来说一说关于 调试 Swift 代码的核心体验的改进 （为运行时故障提供更好的误差信息） 当调试信息可用时 调试程序现在将 为常见的 Swift 运行时故障陷阱 显示原因 而不仅仅是只显示 一个隐晦的“无效指令”崩溃 （调试中增加的稳定性） 更进一步来说 Swift 调试支持程序 现在普遍地更为稳定 为了理解原因 让我们看一看 Swift 在编译时间下 与 Objective-C 交互操作的关键一点

Swift 通过使用 Clang 模型 从 Objective-C 中引入 API 为了解决类型和变量信息问题 LLDB 需要引入 所有在现在的调试环境中可视的 Swift 和 Clang 组件

当这些组件文件对类型有充分信息时 因为 LLDB 对整个计划 以及其所有动态资料库 有一个全局视图 引入 Clang 组件有时会以 在编译时间不会发生的多种方式出现故障 一个常见的故障设想场景 是当不同动态资料库的查询通道 相互有矛盾 （更新） 当这种情况发生时 作为应变计划 LLDB 现在会由于 DWARF 调试信息中的 Swift 调试目的 而引入 C 和 Objective-C 类型 这极大程度上增加了 例如 Xcode 变量视图和数学表达式计算 这类部件的可靠性

Swift 是一个极佳的多用途语言 Swift 不仅对于在 Apple 平台上 构建 app 来说是非常棒的 对其他一些任务来说也很好 由于这个原因 我们认为 对于 Swift 的跨平台支持是非常重要的

Swift 为更多平台提供的官方支持数量 还在不断增长 （官方 Swift 平台支持） 今年 Swift 为 Ubuntu 更新了它的支持 同时也为更多 CentOS 的 Linux 变体 以及 Amazon Linux 2 提供了支持 而 Swift 5.3 也将成为 Windows 的初始支持 在推出后 你可以登陆 Swift.org 来追踪关于它的更多信息更新 这些端口为 Swift 在更多地方被使用 增加了机会

这些地方之一就是 AWS Lambda 无服务器功能是一种容易的方式 来为 app 开发客户 在云端 扩展他们的 app 现在这可以通过使用开放源代码的 Swift AWS 运行时 在 Swift 轻松实现 （Swift AWS Lambda 运行时） 运行时是 100% 开放源代码的 并且在 GitHub 上可用 它也是包括 Swift 工程师们在内的 集体努力的结果 它包含了指令 构建调配 AWS Lambda 指南 以及 AWS Lambda 编程 就像这个在 Xcode 中展示的例子一样 所需的代码量就如同 书写“Hello world”一样简单 这些只是 Swift 生态系统中 令人激动的更新的一部分 接下来 Kyle 会谈一谈 关于 Swift 语言和资料库的改变 谢谢 Ted 你好 我是 Kyle 是 Swift 标准资料库团队的一名成员 （语言及资料库） （Kyle Macomber，Swift 标准资料库） 过去的一年 对于 Swift 语言 和资料库生态系统来说是很重要的一年 让我们先从语言开始讲起 除了 Ted 刚刚提到的改进 我们还为 Swift 5.2 和 Swift 5.3 增加了十余个新的语言部件 由于我们今天没有足够的时间涉及到全部 我想要先将你的注意力引向这些 SE 数字

就像你们中的许多人所了解的 Swift 语言经历了一个公开的演变过程 这些数字中的每一个 都与一个组件文档相对应 你可以在 Swift Evolution 网站 找到这些组件文档 如果你对于该如何帮助 Swift 塑造更好未来感兴趣的话 这个网站也是一个极佳的开始点 好了 让我们开始吧 今年一些最令人激动的新增内容是 对 API 设计师们有用的强大新工具 也就是你们所有人 不论你拥有大众的开源软件程序包 还是与其他开发者一同在同一个团队工作 亦或者只是用 Swift 构造你的个人项目 如果你编码 那么你就要设计 API 让我们从多尾随闭包开始 从最初开始 Swift 就支持尾随闭包 当它是一个闭包时 它是可以让你将一个方法的最终参数 从插入成分中凸显出来的语法糖 尾随闭包已经被证实非常大众 这也不难猜到为什么 它可以在不失去清晰度的情况下 做到更加简明但更少嵌套 使得调用位置更容易被读取 然而 尾随闭包仅限用于最终闭包的限制 导致了它的实用型被限制

在这个案例中 尾随闭包 由于角色的不确定 使得代码更不容易被读取 更糟的是 它改变了从一个调用点完成块 到另一个调用点动画块的意义 对于调用点混淆的顾虑 导致 Swift 风格导引 禁止了尾随闭包的使用 当像这样的一个方法调用 有多个闭包参数时

结果是 如果我们需要追加 额外闭包参数的话 我们许多人会发现我们自己需要 对代码做没必要的重新修改

Swift 5.3 的新功能就是多尾随闭包

这扩充了尾随闭包可以 访问多个闭包参数的优势 并且追加额外闭包并不需要重新修改 多尾随闭包也适用于 DSLs SwiftUI 的全新量规视图被用来表明 一个与某总容量相关的值水平

这里是一个 用于追踪我的花园土酸性值的 圆形 watchOS 量规 番茄对于土壤十分挑剔 所以我希望可以一眼就看到 土壤酸性的确切值 幸运的是 我可以添加一个现在值标签 和最小以及最大值标签 受益于多尾随闭包 量规可以优雅地、循序渐进地 展示它的自定义点 让我们再来看一看 Swift API 设计中 尾随闭包的含义 想象你遇到了这行代码 就比如是在你正着手于的一个讯息 app 总结被用来显示每个对话中 最后一个信息的片段 总结的值是什么？ 调用 take 方法能起到什么作用？ 闭包可能是用来确定采用哪个字符 但是它该如何被应用呢？ 暂停一下 想一想

这是意味着采用符合述语的字符 并舍去不符合的吗？

还是意味着采用符合述语的字符 并舍去其余跟随的字符呢？

在这个例子中 调用点只有在 我们使用包括了参数标签的 普通书写拼法才会清晰

我们可以做得更好 因为人们可以舍去参数标签 所以假设他们会这么做 就是最好的命名方法 比“take”更好的叫法也许是“prefix” 表明了结果是由集合的开始所决定的 实际上 当它在很久之前的 Swift 3.1 中 被添加到标准资料库时 prefix(while 就是这个方法 最终被定下来的名字 同样的引导也适用于更复杂的 API 包括那些有多尾随闭包的 一个方法的基本名称 能够阐明其第一个尾随闭包的角色 是很重要的 因为就算它不是这个方法的第一参数 它的标签也会被丢弃 接下来 让我们来讨论一下 KeyPath 表达式功能 回到 Swift 4.1 时 我们介绍了智能 KeyPath 这种类别表示的是未对 能被用来获得和设置底层值的属性 进行引用

当你设计 API 时 如果你期待调试点成为 一个简单性质访问权 那么 KeyPath 是功能参数的 一个诱人选择 因为它们更加简明 但却更少嵌套 在这个例子中 我从Ruby 中 借用了一个算法 块编码 它是一个对邻近元素组成集合的适配器 但同时它们的密钥是相等的 我碰巧有一份 我朋友和家人鞋码大小的清单 一双新的鞋向来是一份很好的礼物 我可以通过分类 并按照鞋码将我的联系人划分的方式 得到一个快速概览 如果我需要将一双鞋子转送 看起来我会选择 Charles 当然 每隔一段时间 你会接触到一个不仅是简单性质访问权的 应用案例 比如说 你正购买没有半码的凉鞋

为了支持所有这些调用点 你必须复制声明 在新的 Swift 5.2 中 你可以把 KeyPath 表达式作为一个功能

这意味着你可以在任意一个有配套签名的 功能参数中 通过一个 KeyPath 参数 你也可以删除你在过去添加的 任意复制声明 以此来同意 KeyPaths

接下来 我要向你介绍 @main 一个基于类型的项目入口点工具 每个项目都需要以某种方法来开始执行 在这里 我用全新的参数解析包 来声明一个简单工具 将“你好” 印在命令行的一个名称上

但是要求开始执行的样板文件 和项目本身 是一样长的 使得声明氛围消失了

自从 Swift 1.0 以来 你可以 在你的 AppDelegate 内 使用 UIApplicationMain 属性 来告诉编译器去生成一个 在你的 app 中暗含的 main.swift 在 Swift 5.3 中 我们生成并大众化了 这项功能

如果你是一个资料库作者 那么你只需要在你希望用户 获得进入点的协议或父类中 声明一个静态主方法

对于 ArgumentParser 来说 这是 ParasableCommand 这能够使你的用户标记 @main 类 并且使编译器能够生成 一个在你的 app 中暗含的 main.swift 这个基本的授权项目进入点的方法 应该可以更容易地被建造并运行起来 无论你正着力于一个命令模式工具 一个已有的、全新的

或是完全创新的 app 我们迫不及待地想要看到你可以 如何运用这些强大的全新 API 设计工具 接下来 我想要强调一些 消除样板文件并增加表达度的 语言增强功能

让我们从闭包中内隐 self 的 增强可用性说起 为了将注意力引到潜在的引用循环上 Swift 要求在避开捕捉它的闭包上 明确地使用“self” 但是当你被要求连续包含一些 self.s 它可能开始会感到有一些冗长

在新的 Swift 5.3 中 如果你在捕捉列表里包含了“self” 那么你可以将它从闭包主体内删除

你仍然会被要求明确你捕捉 self 的目的 但是现在这个明确性的代价仅仅是 一个单一声明

然而有时候 仅仅是一个 self. 的使用 都会让人感到不必要 就像在 SwiftUI 中 self 被当作一个值类型 使得循环引用的可能性减少 在 Swift 5.3 中 我很高兴地告诉你 如果 self 是一个结构体或是一个枚举 你可以将它从闭包中完全删除

我们认为这些改良会增加信噪比 在闭包内与 self 明确使用相关的 编译器错误的信噪比 减少在没有适当的考虑下 随意改写 self. 的几率 接下来 让我们聊一聊多重异常捕获

在过去 do-catch 语句 不如 switch 语句那么有表现力 导致人们在 catch 子句中 使用嵌套开关 在 Swift 5.3 中 我们扩展了 catch 子句的语法 使得开关语句能够拥有完整的能力

这使得你可以摧毁 这类和 do-catch 语句直接匹配的 多语句模式 也使其更加容易被读取

接下来 让我们一起看一看 我们对于枚举类做出的几个改进 自从 Swift 4.1 以来 编译器就能够为广泛的不同类 合成公平且可哈希的一致性

有些时候 虽然你遇到 有比较运算符却很不方便的情况 我很高兴地告诉你 在 Swift 5.3 中 编译器学会了如何为了使枚举类合格 而合成同等的一致性 接下来 让我们来讨论一下 枚举实例作为协议证人的情况 看一看这两个调用点 文件破损是一个静态变量 还是一个枚举实例？

密钥未找到是一个静态函数 还是一个枚举实例？

静态变量及静态函数：

枚举实例 这两个声明的调用点是完全相同的

认识到这一点后 在 Swift 5.3 中 我们加强了枚举实例 从而使得他们现在可以被用来履行 静态变量以及静态函数的协议要求 去年 Swift 为嵌入式 DSLs 增加了支持 以此增强了 SwiftUI 的声明式语法

这包含了集体视图的子级闭包生成器 以及像 if-else 一样的基础控制流语句

我非常兴奋地告诉你 在 Swift 5.3 中 我们扩展了嵌入式 DSLs 来为符合控制流语句的模式提供支持 比如 if-let 和 switch

在这里 我可以 通过使用一个 switch 语句 组成一个含有我喜爱的动物的相册 在这个可卷动的垂直堆栈中 使不同的图像布局交替 接下来 我将向你介绍生成器推断 在这里 我已经写好了一个 app 用于追踪我在读书俱乐部中 正在阅读的书籍

我的首要用户界面有一个主要窗口 而我的 app 设置则有一个使用偏好窗口 在之前 为了像这样在主体顶层 使用 DSL 语法 需要用特定的生成器属性来标记它 但有了 Swift 5.3 我可以很激动的告诉你 生成器属性将不再被需要 因为我们教会编译器 如何从协议需求中得出推论

今年 SwiftUI 添加了非常多新的功能 如果你想要了解更多的话 我建议你观看“SwiftUI 的创新”板块 （SwiftUI 的创新 - WWDC 2020) 现在我想要变换一下话题 来聊一聊 从 SDK 中开始的 一些你可用的强大的最新 Swift API 让我们从 Float 16 开始 （更新） Float 16 是一个 IEEE 754 标准浮点格式 这在 Swift 5.3 中是全新的

就像它的名字一样 Float 16 只占用两个字节的内存 相反地 一个单精度 float 则要占用四个字节

因为 Float 16 只有 单精度 float 一半的大小 你可以在一个 SIMD 登记或页面内存中 放入两个 Float 16 这在可支持的硬件中 通常会导致性能表现的加倍

但也要注意的是 作为一个更小的数据类 它也有着更局限的精度和范围 所以在使用 Float 16 时 对翻译原本执行双精度或 float 的代码 要多加小心

更多关于 Float 16 的内容 我建议你观看 我们准备的“Swift 中的数值计算”板块 （查看 Swift 中的数值计算 WWDC 2020) 接下来 让我们来聊一聊 Apple Archive 一个新的档案模块格式 它基于 Apple 所使用来发布 OS 更新的 经过考验的科技 （档案模块格式） 它被优化以获得快速且多线程的压缩 它带有访达集合、一个命令行工具 以及许多其它强大的功能 包括惯用 Swift API 用 Apple Archive 有效地压缩以及存档一个资源目录 就是这么简单

我希望你的注意力可以转向 文件流构造器 它影响了今年我们介绍的另一个新资料库 Swift System Swift 系统-- 系统访问惯用的 Swift 界面 Swift System 为了 Apple Archive 一样的低级系统 给系统访问以及 currency 类 提供了现代化惯用界面 （低级 currency 类） 通过达尔文覆盖图引入的 不成熟的弱类型界面 有可能过分细致且容易出错

Swift System 通过 运用技术来覆盖这些 API 比如 强类型的 RawRepresentable 结构 错误处理、默认参数 名称空间以及函数重载 为一个更加惯用的 SDK Swift System 层 奠定了基础 （高性能 隐私敏感日志模块） 最后 让我们一起看一看 一些关于 OSLog 的改进 OSLog 是一个统一的日志模块 API 它已经被优化至拥有最小额外开销 并被精心制作来防止敏感数据的偶然登陆 （基于字符串插入的 API) 在 Swift 5.3 中 我们已经利用 复杂的编译器优化 来使 OSLog 在极大程度上更快 并拥有更强的表现力 也为字符串插入和格式选项添加了支持 如果你仍在使用 print 作为你的解日志模块解决方案 那么现在就是你重新考虑的完美时机 （在 Swift 中探索日志模块） 如果你想要进一步了解关于这些 API 以及如何利用日志模块 追踪难以再生的漏洞的信息 我建议你观看“Swift 日志模块”板块 （程序包） 最后让我们把注意力移向 数量不断增加的 通过 Swift Package Manager 在 SDK 以外的 API 让我们从 Swift Numerics 开始 Swift Numerics 是一个对数值计算 开放源代码的程序包

Swift Numerics 定义了 所有的基本数学函数 比如 正弦以及对数 使其在某种程度上在泛型中更加有用 并且为复数及算法提供了支持 Swift Numerics 复数 与他们的 C 副本是布局兼容的 但 Swift Numerics 复数更快也更准确

现在在 Swift Numerics GitHub 网页上 还有许多令人兴奋的项目 正在被热烈地讨论 包括近似相等比较 任意精度整数以及十进制浮点数

我们在已经准备好的 “数值计算”板块中 深入探讨了 Swift Numerics 程序包 （探索 Swift 中的数值计算） 接下来 让我们看一看 Swift Argument Parser 一个为解析命令行参数而创造的 开放源代码的 Swift 程序包 早些时候 我们看到了如何使用参数解析 来将“你好”印在命令行的一个名称上

让我们对此扩展一下 通过添加一个整数选项 或带有默认数值的总数

以及一个执行计算机指令 来使其印出“总数”次数的“你好”

现在我们的工具可以更加的奋发有为

它对于它所接受的数值也很智能

引导用户向正确的用法

并包括了一个有丰富文件的帮助屏幕

所有这些以及更多的信息来源于一个程序 它能悠然地展示在一张幻灯片上

最后 我将为你介绍 Swift 基础数据库预览包 预览包为在 Swift 演变过程中 已经被接受的功能 提供访问权 但是它还没有被考虑作为 Swift 官方发布的一部分 通过尽快的获取新的产品功能 我们认为我们可以使 Swift 变得更好 作为努力的一部分 我们也使 Swift 演变提案 能够更轻松地被预览 在过去 这会意味着建造整个编译堆栈 现在 你能以一个独立的 Swift PM 程序包的形式 向一个标准资料库功能提案 提供安装启用

我们已经将预览包 种入 SE-0270 的功能中 它包含了集合的自范围运营 并且支持范围集类型 我非常建议你试一试 当我们推出新的平台以及涉及新的领域时 Swift 资料库的未来 就已经在现在被塑造了 而当我们不断改善开放源代码程序包时 Swift 资料库的未来 在现在已经被塑造则就是明摆的事了 我们有意决定 在仍然可以对这些程序包修改的时候 提早发布它们 并在 GitHub 上通过社群的力量 一同开发完善它们

试试他们吧！提出一个问题 打开一个 pull request

再也没有比现在更好的时间了 也再不会比现在更容易融入并造成影响了 我希望你也和我们一样 对新的 Swift 发布感到兴奋 我们迫不及待地想要看看你构建的 app 也希望你能享受 WWDC 的剩余部分 感谢观看！