Chris Lattner 讲述 Swift 起源故事

做者：Ole Begemann，原文连接，原文日期：2019-02-18 译者：jojotov；校对：numbbbbb，WAMaker；定稿：Pancf

在 新推出的 Swift 社区播客第一集 中，Chris Lattner, Garric Nahapetian, 和 John Sundell 讲述了关于 Swift 起源的故事和 Swift 社区的现状。

本文是我整理出的一些比较有趣的东西（为了能更好地阅读而作了部分修改）。你能够看到我主要引用了 Chris Lattner 的讲话，由于我认为他对于 Swift 是如何被创造出来的描述是最值得保留下去的。但这并不表明 John 和 Garric 所说的东西没那么有趣。你真的应该去完整地收听整集播客——反正所花的时间和阅读本文相差无几。

Swift 社区播客 自己也很是值得关注。做为一个让你能够经过各类方式进行贡献的项目，它很是符合咱们的预期（上面提到的三位嘉宾在第一集中谈到了更多细节）。在本文的完成过程当中，个人工做主要在 creating the transcript 这个 Issue 上进行，甚至在代码格式部分和编辑机器生成的文本部分收到了许多来自于社区的帮助。在此对全部提供过帮助的人表示感谢！

你能够在 GitHub 上找到 完整的记录副本（WebVTT 格式）。全部的播客都是由 CC-BY 4.0 受权。

---

Swift 的起源

（开始于 16:59）

Crhis Lattner: 关于这件事，我必须从 WWDC 2010 开始讲起。当时咱们刚刚上线了 Clang 对 C++ 的支持，很是多的人在这件事上面花费了极其巨大的精力。我对这件事感到很是开心的同时，也有一些烦躁，由于咱们作了太多的细节工做。并且你很难不通过思考直接编写 C++ 代码，“天呐，应该有比如今更好的实现方法吧！”

所以，我与一个叫 Bertrand Serlet 的哥们儿进行了许屡次讨论。Bertrand 当时是软件团队的老大，同时也是一位出类拔萃的工程师。他是一个使人惊叹的人，而且在语言方面有点极客范。当时他正在推动对 Objective-C 的优化工做。我和他进行了许屡次一对一的白板会议。

At the time, Swift was called ‘Shiny’. 在那时，Swift 还叫 ‘Shiny’

Bertrand 负责苹果公司全部的软件项目，所以他基本没什么时间。但他老是会让我在工做结束时顺便拜访一下他，看他是否是有空。他常常会呆到很晚，而后咱们会在白板上进行很是认真的讨论。咱们会谈论很是很是多的东西：新语言要达成的目标、一些奇怪的细节如类型系统，而且咱们最终都会把这些讨论变成一份计划书。所以我为他作了这份计划书并演变成构建一个新语言的想法。那时这个新语言还叫作 "Shiny"，寓意着你正在建造一个 很酷的 新东西。^[1] 固然我也是 Firefly 电视节目的粉丝之一。（译者注："Shiny" 的梗源自 2002 年美国电视节目 Firefly，意思至关于真实世界中的 "cool"。）

John Sundell: 当时的文件后缀是 .shiny 吗？

Chris Lattner: 确实如此。你知道在那个时候，这仍是个很小型的项目。真的就只有我和 Bertrand 在讨论这件事。另外就只有一个一样很是出色的工程师 Dave Zarzycki 参与了早期的一些概念上的讨论。

一开始，咱们就天然而然地展开了关于内存管理的讨论。当时，咱们都确信一点就是：必需要有一个好的方法来解决或改善内存管理，而且咱们须要确保 内存安全。于是，你必须有一个自动内存管理功能。

为了达到自动内存管理的目标，咱们有史以来第一次以 Swift 的内部设计讨论为起点，并最终在 Objective-C 中实现了此特性。

首先想到的一个关键功能就是 ARC，同时咱们须要让编译器自身支持这个功能，而不是经过运行时来实现。Objective-C 当时使用 libauto 垃圾回收系统，但它有着一大堆问题。所以为了达到自动内存管理的目标，咱们有史以来第一次以 Swift 的内部设计讨论为起点，并最终在 Objective-C 中实现了此特性。随后有许多的东西都是这样产生的，包括 ARC 和 modules 甚至 literals 及更多相似的功能，它们的确都是由 Swift 的幕后开发主导的。^[2]

John Sundell: 因此在当时，你脑海里已经有许多关于 Shiny 的特性，最后它们都在 Swift 中实现了。但你曾经说过，“咱们并不想一直等待新语言开发完成。咱们应该把这些很是吸引人的特性加入到 Objective-C 中。”

在构建一个新的语言时，你必须一直问本身，‘为何不直接优化现有的语言’，这是幕后构思过程的一部分。

Chris Lattner: 或许如今看来，Swift 的出现是必然的，但若是你从另外一个角度思考这个问题，在当时并非全部人都能认识到这一点，甚至连我也不能肯定。Bertrand 从过去到如今都一直很是的棒，他一直给予咱们极大的鼓励。并且他老是能在质疑中前进。Bertrand 有点相似科学家，他仅仅只是想经过各类途径寻找真相。的确，当时咱们有许多疑虑，但同时也有许多好的想法。包括 Bertrand 在内的不少人一直在推动这项工做。在构建一个新的语言时，你必须一直问本身，‘为何不直接优化现有的语言’，这是幕后构思过程的一部分。而这个问题的答案是，“很显然，咱们应该把现有的优化好”。这也是为何诸如 ARC 的功能会出现。

可是，在 Swift 中，最须要解决的问题是内存安全。在 Objective-C 中，除非去除 C 相关的东西，否则是不可能达到绝对的内存安全。但去除了 C 的 Objective-C 会失去太多的东西， 而它也再也不是 Objective-C 了。

Garric Nahapetian: 没错。所以，把一些 Swift 的特性添加到 Objective-C 中就像是 特洛伊木马 同样，可让你们更容易地信任 Swift ，由于你已经完成了 Objective-C 方面的工做，是这样吗？

Chris Lattner: （这里面）其实有许多有趣的内部动力。我以为咱们很是专一地优化 Objective-C 及其相关的平台。对于开发 Swift 而言，这是一种下降风险的办法。若是说，“咱们要把全部东西都一次性推到重作”，并且不通过任何测试的话，确定会有巨大的风险。但若是你只把“少部分”的东西单独推倒重作，好比一个全新的内存管理系统，而后对它进行迭代、调试并结合社区的力量进行开发的话，就只会产生有限的风险。不过有一点我要说的是，无论是外部的社区仍是苹果内部的社区，貌似都在对咱们说，“为何你要优先考虑这个？咱们就好像是几率论中的 随机漫步 同样。为何你要作这个而不是其余的？”所以，这也成为了一个有趣的动力。

---

初始团队的成长

（开始于 22:49）

Chris Lattner: 苹果拥有着一支很是强大的工程师队伍。那时有很是多的人一块儿维护 Objective-C，这实际上是有点执拗的一件事，但同时这也让咱们在动态库、应用和其余相似的东西上拥有了十足的深度和背景。正因如此，那时有许多关于优化 Objective-C 的想法涌现。自从乔布斯离开并创立 NeXT 以后，许多杰出的人物都一直参与这项工做并写下了大量相关的白皮书。所以，Objective-C 背后有一个极其庞大的社区在推进着。

当时，我和 Bertrand 以及 Dave 讨论过一些想法，我也开始着手编写一个编译器的原型。不过结果很显然，我很难靠本身去构建出全部的东西。因此最后的事情也理所固然地发生了——大约在 2011 年四月的时候咱们与管理层讨论了关于 Swift 的事情，而后也得到批准去调动一小部分人员。Ted Kremenek、Doug Gregor、John McCall 以及一些其余的杰出工程师都是在那时调入 Swift 项目的。如今回头看看，其实挺有意思的，由于当时是第一次有一些语言和设计专家对 Swift 作了批判性的评价。他们反馈了不少严厉的批判。虽然他们的本意并非打击咱们，但他们的确说的很对——这个语言当时实在是糟透了。

能让这一切顺利进行有一个关键缘由，就是咱们有机会拉拢一位泛型领域的世界级专家，以及一支构建过 Clang 编译器的团队。同时这支团队也参与过许多不一样的有意思的项目，并可以尽量地发挥他们的工程天赋。虽然他们只是帮助推动和开发构建的一部分人员，但却相当重要。

John Sundell: 在那时 Swift 语言的情况是怎样的？好比，语言的语法是什么样子？编译器的哪部分基础设施已经搭建完成了？它是否是已经接近于原型的阶段甚至更进一步呢？

Chris Lattner: 那时 Swift 已经很是接近原型阶段了。这些资料都是彻底公开的，由于在 GitHub 上，变动历史是彻底公开 的。变动日志 虽然不能彻底追溯全部的历史变动，但已经足够了。

在 Doug 加入以前，Swift 并无泛型系统。当时咱们很想作一个泛型系统，但我不是颇有自信能独自设计出来，Doug 却作到了。我记得在很早的时候，John 曾经接手过一个项目，让一个相似语法分析器的东西变得能够真正生成代码。Doug 所作的事情大概就是这样。

有不少零碎的事情我不太记得了，但有些东西我却一直记忆犹新。我记得 var 和 func 就是从最初就制定好的。早期的 Swift 中不少基本语法都和如今的 Swift 语法很是接近。

当你构建同样新东西的时候，一般想法是领先于文档的，而文档又先于代码。咱们当时状况也很是相似。到如今，想法已经领先于代码很是之多了，这都是无可避免的。

当时的 Swift 已经十分接近于一个原型了。但仍有许许多多的想法未实现。当你构建同样新东西的时候，一般想法是先于文档的，而文档又是先于代码。咱们当时状况也很是相似。到如今，想法已经领先于代码很是之多了，这都是无可避免的。

---

关于 Craig Federighi

（开始于 26:10）

Chris Lattner: 对于社区很是重要的另外一位伙伴名叫 Craig Federighi。Craig 在苹果社区中很是出名。在 2011 年早些时候，他加入了这个项目。那时正好 Bertrand 从苹果退休，Craig 便接手了他的工做。

说到 Craig，他是一个很是、很是有趣的人。不管在台上仍是台下，他都着非凡的我的魅力。大多数人们都不了解他到底有多么的聪明。他还在许多方面都有着极其深刻的研究。我彻底没想到，他在语言方面懂得不少。他曾为 Groovy 和许多其余类型的语言做为正式参与者工做过，有些语言我甚至还没接触过。并且，他并不像是一位只会谈论策略的高层人员。他一样关心许多细节的事情，例如闭包语法、关键字和其余东西。

Craig 真的是一位很是严格的任务推进者，同时他也推进着 Swift 的实现以及 Swift 与 Objective-C 的联动。不只如此，他还关心着 Objective-C 自己的维护；关心着 API；关心着 Objective-C 的 API 导入到 Swift 后的形态，还有相关的一切。Craig 在积极给予反馈的同时，一直保持着在团队和项目上出乎意料的卓越态度。他的帮助对 Swift 的现状影响很大。

Garric Nahapetian: 这真的很酷，由于他恰好是在 WWDC 2014 的讲台上第一位发表演讲的人。

Chris Lattner: 没错。

John Sundell: 而后他就介绍你出场了，对吧？我还记得那句经典的标语：“没有 C 的 Objective-C”。

我对那句“没有 C 的 Objective-C”标语有着复杂的感受，由于其实我想表达的并非这样。

Chris Lattner: 说实话，我对那句标语有着复杂的感受，由于其实我想表达的并非这样。

John Sundell: 那是句很棒的标语。

Chris Lattner: 在那个时候，以这种方式向社区宣传是很正确的选择。

（……）

在项目的一开始，个人目标实际上是构建一个全栈系统。

Chris Lattner: 至于说为何我当时很矛盾，由于在项目的一开始，个人目标实际上是构建一个全栈系统——分析市面上现有的系统，取其精华，弃其糟粕。并且当时的目标是构建一个能够编写固件、编写脚本、编写移动应用和服务端应用甚至是更底层系统代码的语言，同时在语言层面上并不是只是经过随意堆砌来实现，我要让它在上面说的全部方面都能表现出色。

因此在当时而言，这个方向绝对是正确的。虽然目前 Swift 还没能达到预期，但欣慰的是它的发展将会使它可以在将来拥有这些的能力。

---

文档的重要性

（开始于 30:32）

Chris Lattner: （在这里）我还要最后提到一支团队。你目前所看到的 Swift，它是一个编译器，是一门语言，是一系列 API 的集合，也是一个 IDE。但让这些事情可以成真，并让 Swift 走向大众，离不开开发者发布团队的工做。他们是 Apple 的科技编辑，负责编写如 Swift 编程语言书籍 之类的东西。Swift 的成功和快速适应市场离不开当时第一时间发布的高质量文档和书籍。直到今天，他们仍在维护这些文档，真的很是难以想象。

咱们直接把这些科技编辑拉入了设计讨论会

我记得当时咱们直接把这些科技编辑拉入了设计讨论会。像 Tim Isted、Brian Lanier 和 Alex Martini 这些人，他们在周会上花了大量的时间争论着一些细节问题——“咱们是否应该使用点语法？”“咱们应该使用这个关键字仍是那个关键字？”或者是“咱们是应该把 func 改成 def 吗？”同时还讨论着——类型系统的深度以及 代码生成 算法应如何工做；咱们如何达到较好的性能？字符串 应如何运做？还有各类各样的问题。

若是你能在设计阶段就考虑到如何像你们解释这门语言的话，工做会进行得更顺利。

我见过不少次这种事情，当你构建完一个系统后你还要尝试着解释它。而后当你开始解释这个系统时，真的会陷入一个尴尬的处境，好比：“天啊，我居然还要去解释这个东西是如何工做的”。若是你能够在设计阶段就处理好反馈信息，并引入文档，引入这些关于如何向你们解释的工做，你会进行得更顺利。

---

Swift 的开发工做是一个团队效应

（开始于 34:58）

Chris Lattner: 我想说的是，不少人会说“Chris 发明了 Swift”。虽然个人确在不少年的时间里一直用不一样的方法推进着 Swift 的开发，也算是带领着整个项目，但事实上其实他们都忽略了一点，有数以百计的人为 Swift 的许多关键问题做出了贡献。例如构建调试器、构建 IDE、构建 Playgrounds、构建教育相关的内容、构建各类东西以及相关的社区。

我在许多地方都不如他们优秀。他们几乎组成了一个不只是在 Apple 内部，同时活跃于 Apple 以外的社区，并一块儿推进着 Swift 相关功能的构建，并以他们本身的方式作着贡献。这就是为何 Swift 能发展的现在的规模，我认为这也是 Swift 能一直成长下去的缘由。

Garric Nahapetian: 这也是咱们录制这集播客的缘由之一——让这些在幕后作过贡献的人能够站在聚光灯下。

---

不要像编译器开发者同样写 Swift

（开始于 42:15）

Chris Lattner: 有件事我以为很神奇，大家两个写的 Swift 代码比我写的还多。我可能对 Swift 的内部实现、它为何会是这样的、它是如何作到某些事的，以及它是如何运做的比较了解，但大家却拥有着真正以 Swift 来构建产品的经验

John Sundell: 是的，这颇有趣。有许多许多人在为 Swift 项目工做，为它的编译器工做，并且他们大部分时间都在写 C++。我想顺便问一下，这种感受是怎样的？你设计了这门很是酷的语言，你们也逐渐开始使用它了，但你却还在使用 C++。

Chris Lattner: （大笑） 这让我痛不欲生。这真的太可怕了。就像老天开的玩笑同样，强制我一直在写 C++。

---

关于社区反馈

（开始于 43:11）

Chris Lattner: 为何 Swift 如今能发展得这么好，拥有一个庞大的的社区，并且你们都习惯于在上面写博客，这确定是都主要缘由之一对吧？社区的反馈的确影响了 Swift 1 和 2 。那些抱怨就像是提醒咱们的信号同样，“这根本不合理”，“我在这上面遇到了问题，还有那个和另外的都遇到了问题”。这些的确帮了咱们不少，特别是在优化、排期和推进最终的 Swift 版本方面。

早期的社区反馈的确影响了 Swift 1 和 2。

比较意外，也能够说是咱们有意为之的是，在 Swift 1 中没有加入错误处理机制。同时咱们也没有加入协议扩展，这些能力咱们绝对是但愿 Swift 可以拥有的，但只是错过了发布日程。所以咱们很清楚必需要去构建这些功能，但在第一两年间这些东西倒是直接由社区最终推进完成的。而后当 Swift 开源，Swift Evolution 变成了一个伟大的项目。这个项目可能在人们的时间效率优化方面表现并不理想，但它倒是让 Swift 非比寻常的重要因素。我想这项荣誉属于全部在社区中花时间为 Swift 的功能优化和工做推动提供帮助的人。

John Sundell: 我所想到的就是，不只是那些文章和内容，同时包括开源在内的全部东西，都是如何大量反哺了 Swift 自身。例如，相似 Codable 功能，在它未完成以前人们会开发数以千计的 JSON 映射库。我也是其中之一。我曾经构建了 Unbox ，由于在 Objective-C 中你不须要在这方面花费许多时间和精力。你只须要说，这是个字典，那咱们就访问它的某个 Key 而后假设返回结果永远是字符串。但一旦你坐下来把一样的代码以 Swift 实现的话，你就会发现须要用到大量的 if let。所以我能想象到这些你们都尝试解决的东西，绝对会以不一样的方式反哺 Swift 自身的设计进程。

Chris Lattner: 是的，这无可厚非。并且 Codable 的设计来自于 Apple 的一支非 Swift 核心开发团队的动态库团队。他们对这个工做真的颇有耐心，他们实现并推进着它，而且一直支持着它上线。

很难想象到底社区影响了 Swift 多少。

社区呈现了各类各样的东西对吧？好比 Result。为何 Result 要加入到 Swift 5 中？由于咱们一次又一次地构造了它。即便 核心团队 不但愿有一个 Result 类型，由于这仿佛是语言的失败体现；即便咱们一致认为 Result 类型不是必要的。但社区中却一直有清晰且强烈的声音，“大家看，咱们须要它。无论在长期看来它是否理想，但咱们如今的确须要。”所以社区真的影响了不少东西。并且你可能不可思议到底社区影响了 Swift 多少。

---

关于初始预期

（开始于 46:07）

John Sundell: 对于 Swift 的现状，以及你发布 Swift 后它的改变，这些是否都符合你的预期呢？通过了这些年，对于你在最初阶段的想法，Swift 如今有多少是符合的？

当 Swift 1 发布时，咱们也有一些疑问，咱们是否能够在 Objective-C 的社区中得到一席之地？咱们是否能在 iOS 的生态系统中得到一席之地，或者是将会分红几派？

Chris Lattner: 这么说吧，我以为预期也会随时间改变。若是回到 2010-2011 年，我并无预想着它会有多成功。我认可当时我只是以为这是个有趣的业余项目。这本来就是个填补夜晚和周末时间的东西。你知道，在整日的工做后再去作一个业余项目是颇有趣也很具挑战性的。当它愈来愈接近完成，并直到 Swift 1 发布时，咱们都一些疑问——咱们是否能够在 Objective-C 的社区中得到一席之地？咱们是否能在 iOS 的生态系统中得到一席之地，或者是将会分红几派？咱们当时的确有这样的疑虑。如今我能够说我会感到很欣慰，由于我以为社区中绝大多数人都对 Swift 持乐观态度。

Chris Lattner: 不过如今依然有新的领域等待探索。Swift 在服务端的表现一直愈来愈好，但仍有大量的工做须要完成。在外部，也有许多不一样的社区活跃着。我对数字和 机器学习的社区 特别感兴趣，这些对全世界都有重要的意义。在这些社区中，有着许多有趣的人，我以为 Swift 在这里能够发展得很好。

Swift 的全球制霸只是一个开玩笑的目标，但它来源于使用和热爱 Swift 的人们的信念。

我有时会开玩笑地说，咱们的目标是 Swift 全球制霸。这只是一个玩笑目标，但它来源于使用和热爱 Swift 的人们的信念。若是真是这样的话，我会很是愿意把这份愉悦带给人们，并帮助改善整个世界。现实中仍有许多让人头痛的系统对吧？仍有许多人还在写着 C 语言代码。就那些 bug 和安全脆弱性 来讲，真是让人感受十分不幸。同时，咱们还要面对生态系统的问题，以及许多其余的挑战要征服，这都是咱们做为一个社区能够完成的。在这方面，我认为有着无限的可能。

---

在 Apple 社区之外推广 Swift

（开始于 50:18）

Chris Lattner: 尽管人们如今都是以积极、乐观的态度来讨论 Swift，可 Swift 仍有许多问题。我以为咱们必须保持开放的态度来讨论这个，并把它看做一个解决问题的练习。主要的问题集中在 Linux 生态系统上面，与之相比，Windows 生态系统 的问题简直不值一提。为了让 Swift 的受众更普遍，咱们真的还有许多工做要作。

Swift 仍有许多问题。主要的问题集中在 Linux 生态系统上面。Swift 在 Windows 生态系统 的问题简直不值一提。

Chris Lattner: 咱们的目标是打造一个不排外的社区。可事与愿违的是，若是你不是一名 Apple 开发者，你可能会在搜索 Swift 相关的东西时感到融入不了社区，由于搜索结果都是一些 iOS 相关的讨论。

若是你不是一名 Apple 开发者，你可能会在搜索 Swift 相关的东西时感到融入不了社区，由于搜索结果都是一些 iOS 相关的讨论。

John Sundell: 彻底正确。好比“这是如何在 UIViewController 中完成它的方法。”

Chris Lattner: 没错。这会让你以为本身是个外来者，但这并非咱们的初衷。我认为这不是有意为之的，但它倒是真实存在的。这正是咱们社区所面对的一大挑战。我目前还不知道有没有比较完美解决方案，不过我想咱们总会找到的。

---

关于 Swift 的演进

（开始于 55:12）

Chris Lattner: （关于 Swift 的演进）这是个很是复杂的事情，我大概要好几个小时才能所有讲完。若是简短地说一下个人想法——开放要好于封闭。若是你能让更多人参与，那么你确定能获得一个更好的结果。我想 Swift Evolution 的项目进展有不少问题，Garric 也列举了一些。但这不妨碍它是一个很好的东西。同时有一点我认为是有益的，就是它很好地减缓了语言的演进。由于当心谨慎地发展一个语言总比过快地发展好。

我以为强制地推进一系列文档进展也是一件很好的事情，由于文档是十分重要的。Swift Evolution 项目引领了苹果与社区在某种规范下，以不一样的方式进行合做，这不只有趣，也是很是棒的一件事。

我不认为 Swift Evolution 项目是一成不变的。在这几年的时间里，它在不一样方面都发生了改变。同时，咱们一直在艰难地权衡着它的目的——究竟是为社区输出设计规范仍是帮助社区肯定优先级？对咱们来讲，这是个具备挑战性的问题，由于当你把它彻底交给社区去执行时，你可能会失去一些细节的东西。但在一些大方向上，整个 Swift 的世界都是认同的——好比 并发性。

这是咱们的一次很是大的尝试，并且经过一个自底向上的社区流程来实现它不是一件容易的事。所以不少事对我来讲都是未知的。我以为 Swift Evolution 是一个很棒的项目。我也很开心咱们如今拥有这个项目。尽管我赞成它不是咱们所惟一拥有的，也不该该是惟一的，但我仍以为它绝对是业界标杆之一。

（……）

我一直在寻找 Swift 包管理生态系统的催化剂，到底应该以服务端 Swift 的社区为起点，仍是以机器学习社区为起点。

从某种意义上来讲，Swift 的每个变更，都须要一段时间来消化。当一个大的新能力出现时，社区都须要一段时间来弄明白它、应用它、找出它的使用场景和它如何与其余功能兼容。所以，花费的这些时间都是值得的。我从 Swift Evolution 所认识到的最重要的事，就是社区的合理推进所带来的力量。Swift Evolution 真的为咱们汇集了许多来自社区的语言极客，让他们同时关注 Swift 项目一个特定方面。我一直在寻找 Swift 包管理生态系统发展的催化剂，到底应该以服务端 Swift 的社区为起点，仍是把机器学习社区汇集起来干点大事。

咱们如何去寻找这种催化剂——让你们在合适的地方聚在一块儿，经过他们本身的力量构建一个项目，发挥他们的能力和天赋，让你们协做工做？

本文由 SwiftGG 翻译组翻译，已经得到做者翻译受权，最新文章请访问 swift.gg。

---

1. Jordan Rose 分享了一则与 Shiny 这个名字相关的佚事 ：.swiftmodule 文件中的“魔法数字”是 E2 9C A8 0E。它的前三个字节是 ✨ 的 UTF-8 字符（U+2728 SPARKLES）。 ↩︎

2. Greg Parker 声称 ARC 只是间接地从 Swift 的开发过程当中产生：ARC 的实现早于 Swift 的实现。但在幕后的工做中，Swift 早期的设想的确推动了管理层提供必要的资源去构建和部署 ObjC 的 ARC。 ↩︎