一。 五。 零。我们迎来了第 150 个 issues! 了不起的成就，值得一提的是，这也是今年最后一篇通讯。

首先感谢 Jesse Squires 启动了这个项目并一直维护到第 100 期。同时还要谢谢 Kristaps Grinbergs 在过去几个月的幕后帮助。感谢所有其他作者和在幕后默默奉献的人。有了你们，Swift Weekly Brief 才能继续下去！

最后，非常感谢大家阅读和分享新闻通讯！当我从 Jesse 接手这个项目时，我这样做主要有两个原因：我想 及时了解 Swift 的最新动态，并向其他感兴趣的人分享。回过头看这个目标已经达成了，让我们一起期待明年，继续前进吧。

话虽如此，我希望大家在接近 2019 年的尾声，度过愉快的每一天。

入门任务

• SR-11900 [Compiler] swift help doesn’t work
• SR-11905 [Compiler] Objective-C interop allows creation of undefined behavior
• SR-11918 [Compiler] Reject the combination of -enable-testing and -enable-library-evolution

社区新闻

Tanner Nelson 发布了 Vapor 4! 🥳

Paul Hudson 发布了 Swift for Good，一本由 20 个不同作者编写的有关 Swift 话题的书，这本书的所有收入都将捐赠慈善机构。

Bruno Rocha 写了一篇文章 关于 OptionSet 在 Swift 编译器中的工作原理。

合并请求

Ankit Aggarwal 合并了一个 pull request允许使用通过 swiftpm 命令构建的二进制文件。

Rintaro Ishizaki 新建了一个 pull request 关于重用编译器对象以实现更高效的代码补全。更快更优雅！

Erik Eckstein 合并了一个 pull request 添加了一个 cross-module optimization 的选项。

新晋提案

SE-0268: Refine didSet Semantics 被接受。

The proposal has been accepted as it was originally proposed, prior to the second review.

The change overall received considerable support, despite being semantic-breaking in rare cases. Being able to make mutations in-place is an important performance win and one that many current users might already be expecting.

The second review proposed a small alteration to the original proposal: to warn on implicit use of didSet, because in the original review some reviewers felt that accessing the implicit parameter in the body of the function resulting in the fetching behavior could be harmful, so proposed a deprecation warning to be silenced by adding the argument explicitly. During the second review, it became clear that the feeling of most commenters was that the increased verbosity (and new warnings) did not justify the change. The core team agrees with the feedback, and so has accepted the original proposal.

审核中提案

SE-0270: Add Collection Operations on Noncontiguous Elements 正在审核中.

The proposal was returned for revision in order to investigate splitting it into smaller pieces. Nate Cook, the proposal author, has chosen to make several revisions, the most significant of which is to remove several sets of methods; you can see the raw difference here. The Core Team has elected to run a review of the proposal as revised rather than sending it back into the pitch phase.

It sometimes happens with re-reviews that the Core Team has substantively approved parts of the proposal and is asking the community to provide feedback on specific revisions. That is not the case here because the Core Team did not feel like it received a strong signal on the core proposal. Accordingly, please consider this to be a de novo review and provide feedback on the full proposal.

SE-0272: Package Manager Binary Dependencies 正在审核中。

SwiftPM currently supports source-only packages for several languages, and with a very proscriptive build model which considerably limits exactly how the compilation of the source can be performed. While this makes packages consistent and to some extent “simple”, it limits their use in several important cases:

• Software vendors who wish to provide easy integration with the package manager, but do not deliver source code, cannot integrate.
• Existing code bases which would like to integrate “simply” with SwiftPM, but require more complicated build processes, have no recourse.

For example, consider these use cases:

• Someone wants to create a Swift package for generating LLVM code. However, LLVM’s build process is far more complex than can be currently fit into SwiftPM’s build model. This makes building an easy to use package difficult.
• A third-party wants to provide a Swift SDK for easily integrating their service with server-side Swift applications. The SDK itself relies on substantial amounts of internal infrastructure the company does not want to make available as open source.
• A large company has an internal team which wants to deliver a Swift package for use in their iOS applications, but for for business reasons cannot publish the source code.

This proposal defines a new SwiftPM feature to allow SwiftPM to accept some forms of “binary packages”. This proposal is intentionally written to address the above use cases explicitly, it does not define a general purpose “binary artifact” mechanism intended to address other use cases (such as accelerating build performance).

SE-0273: Package Manager Conditional Target Dependencies 正在审核中。

This proposal introduces the ability for Swift package authors to conditionalize target dependencies on platform and configuration with a similar syntax to the one introduced in SE-0238 for build settings. This gives developers more flexibility to describe complex target dependencies to support multiple platforms or different configuration environments.

This proposal resolves two use cases that the current version of the Package Manager doesn’t support very well. In the first scenario, packages that span multiple platforms may need to depend on different libraries depending on the platform, as can be the case for low-level, platform-specific code. In a second scenario, packages may want to link against libraries only in certain configurations, for example when importing debug libraries, which do not make sense to build and link in release builds, or when importing instrumentation logic, which only make sense in release builds when the developer can not benefit from debugging.

This proposal attempts to bring solutions to those use cases by allowing package authors to define under what build environments dependencies need to be built and linked against targets.

论坛动向

Joe Groff 分享了一些关于范型元数据的 prespecialization。

One source of memory and performance overhead in Swift code is the instantiation and fetching of type metadata. Even though generic specialization eliminates the need for type metadata in most fully-specialized code, we still need the metadata in many frequently-occurring situations:

• Objects always need their class metadata, which serves as the “isa” pointer with the object’s method table and other dynamic metadata.
• When putting a value inside an existential box, the type metadata for the value’s type is stored in the box to represent its dynamic type.
• When calling into unspecialized code, type metadata for the generic type arguments has to be formed. Code may remain unspecialized because it crosses ABI boundaries or is invoked via dynamic reflection.

Tom Doron 分享了 Swift 服务器端工作组十二月的见面会议笔记。

Ian Partridge and Chris Bailey let the group know that following a review by IBM of its open source priorities, it has been decided that they will not be continuing to work on Swift in 2020. As a result, they are both standing down from the workgroup.

Ian Partridge will work to hand over responsibilities for the Swift Docker images and suggested a potential new owner from the community.

Ben Cohen 起草了一份草案以公开 Swift 的 modify 存取器。

We propose the introduction of a new keyword, modify, for implementing mutable computed properties and subscripts, alongside the current get and set.

The bodies of modify implementations will be coroutines, and they will introduce a new contextual keyword, yield, that will be used to yield a value to be modified back to the caller. Control will resume after the yield when the caller returns.

This modify feature is currently available (but not supported) from Swift 5.0 as _modify, for experimentation purposes when reviewing this proposal.

Matthew Johnson 起草了一份草案以引入匿名的 struct 类型。

This proposal introduces anonymous structs using closure-inspired syntactic sugar as an alternative to a more verbose local struct declaration. As with closures, trailing syntax is supported.

While Swift has often been called a protocol-oriented language it still lacks some features necessary to facilitate protocol-oriented library designs in practice. One missing feature is syntactic support for ad-hoc, single-use conformances on par with the expressivity that closures provide for ad-hoc, single-use functions.

Local type declarations involve a lot of syntactic ceremony that is unnecessary for singe-use types. This ceremony includes a name, explicit protocol conformance declarations, and fully written declarations for all members. In addition to the ceremony of the local type declaration itself, use of the type requires explicit instantiation, which may itself be verbose if there are several stored properties to initialize.

尾声

A “funny” Swift thing.