上个星期新的播客节目Swift Community Podcast隆重登场。这个播客能促进 Swift 开发社区的发展,我鼓励大家都一起参与进来。
我认为这是一个非常令人兴奋的项目,我很期待 Swift 社区逐渐变大变强!
不用多说了,接下来市 Swift 开源社区最近两周的更新。
入门任务
- SR-9670 [Compiler] Driver should accept
-serialize-diagnostics-path
for the interpret mode - SR-9677 [Comiler] Using break with unresolved label inside loops produces misleading diagnostic
播客
John, Garric 和 Chris 新开了一个 Swift 社区的播客节目,它们在播客中讨论了当年对于 Swift 的初印象。
社区新闻
Jeremy Howard 完成了一项研究项目意为解答这个问题:如果在 Mac 和 Linux 平台进行高性能的数学编程,Swift 是一门好的语言吗?
Joe Groff 分享了一个关于 opaque result 类型的原型实现方案。
合并请求
Arnold Schwaighofer merged a pull request that has non-escaping context allocated on the stack.
John McCall merged a pull request that combines two code paths, fixing an edge case neither one could handle. 🎉
新晋提案
SE-0239: Add Codable
conformance to Range
types 被接受。
非常感谢大家在审核期间提供的非常有见地的反馈。这些反馈为 Swift 社区在 Codable 最佳实践上提供了参考。
关于提案本身,核心团队决定接受它,并通过修改提案以包括编码格式的更多细节。所选择的编码对二进制兼容性以及开发者来说是很重要。未来的提议应该包括更多细节 - 并在必要时 - 包含选择编码的基本原理。此外,如果还记录了标准库类型的当前所选的编码,那么用户可以选择直接使用,或按其需要自定义其编码逻辑,这些内容都是有参考意义的。
此外,核心团队决定为
ContiguousArray
新添加Codable
扩展的支持,而现在的标准库并不支持这一项。
审核中提案
SE-0240: Ordered Collection Diffing 正在审核中。
这份提案为标准库进行了补充,为差异提供了交换格式,并为有序集合类型提供了差异/修补功能。
如今在状态的表示,初始化和转换上需要编写许多容易出错的代码。这个提议的灵感来自于与文本文件交互时
diffutils
套件,以及我们不愿用libgit2
来解决代码中的类似问题。许多状态管理模式将受益于此领域的改进,包括撤消/重做堆栈,分代存储以及将差异内容同步到服务器。
论坛动向
Stephen Celis 和 Greg Titus 起草了一份关于将 key path 表达式作为函数使用的提案 。
在 Swift 中使用一次性闭包,从根类型遍历到值类型是很常见的用法。参考下面的
User
结构体:
通过运用
map
方法可以将一组用户转变成对于的一组电子邮件地址:
类似地,
filter
可以以用户是否为管理员的条件过滤出一组新的用户:
上面的写法很简洁,但其实可以通过一个更简洁的语法来描述它们:key paths。
Loïc Lecrenier 起草了一份提案关于为 Swift packages 添加模糊测试支持。
最近,我写了一个类似于
libFuzzer
的 Swift fuzzer,但我发现 SwiftPM 不允许自定义相关的构建设置,因此我不得不 fork SwiftPM 另一个分支并加上自己的代码。使用覆盖引导的模糊测试需要测试目标配置 LLVM 的 SanitizerCoverage,你可以通过使用swiftc
的先行版并加入-sanitize=fuzzer
参数来实现。同时多亏了 SE-0238,SwiftPM 现在支持自定义构建设置,因此可以将该选项添加到包中,但仅适用于在根包中声明的目标,而不适用于在依赖项中声明的目标。此外,对目标进行测试以生成的二进制文件不适合用于除模糊测试之外的用途,因此我认为最好通过使用单独的构建配置来隔离模糊测试的二进制文件,而不是简单的 debug 或 release 配置。
Saleem Abdulrasool 分享了 Winodws 平台上对 Swift 支持的进展情况。
通过最近对 Windows 平台上构建
swift-corelibs-foundation
的理解和实践,我认为若要在 Windows 上运行 Foundation 还需:
- 移植剩余模块的接口: Progress,Thread,FileManager 和 Host
- 修复 ForeignClassMetadata 策略的 VWT
- 修复从标准库导出的 protocol witness table
- 确定 curl/libxml2 链接的行为正确性
前三个更具技术性,接口的实现只需要有足够的人花一些时间来处理。第二个则涉及更多的东西,而第三个只是一个 bug。
[..]对于那些对 Windows 平台移植感兴趣的开发者,特别有兴趣帮助在 Windows 上构建运行 Foundation 的开发者,请查看 work in progress pull request。我们当然欢迎你来帮忙我们!
尾声
// 欢迎来到软件开发世界。