前言
本期是 Swift 修改组自主收拾周报的第十六期，每个模块已开端成型。各位读者假如有好的提议，欢迎在文末留言。
欢迎投稿或引荐内容。现在计划每两周周一发布，欢迎情投意合的朋友一同参加周报收拾。
挑选与抛弃，是日子与人生处处需求面对的关口。挑选了Swift社区，就具有了一道最靓丽的景色！
周报精选
新闻和社区：印度将初次成为苹果公司自有出售区域
提案：提案 SE-0382、SE-0388、SE-0389 经过检查
Swift 论坛：提议 Observation 修订
引荐博文：两个新的开源 Swift 库：
Swift Certificates和Swift ASN.1论题评论：
文心一言挑战 ChatGPT，谁更胜一筹？
新闻和社区
印度将初次成为苹果公司自有出售区域
【环球网科技综合报导】3 月 9 日消息，据外媒报导，苹果公司正在改变国际业务的办理办法，推进印度初次成为其自有出售区。
据悉，负责苹果印度、中东、地中海、东欧和非洲区域业务的副总裁休斯阿斯曼（HuguesAsseman）退休后，苹果计划将印度调整成自有出售区域。而阿希什乔杜里（AshishChowdhary）将升职，成为印度区域的负责人，直接向苹果的产品出售负责人报告。
外媒剖析称，作为世界第二大智能手机商场，印度商场关于苹果而言越来越重要。2022 年第 四 季度，苹果在印度商场的出售额创新高。
现在，苹果已开端在印度出产一些 iPhone 型号，包含 iPhone14 。此外，苹果计划于本年晚些时候在该国开设第一家零售店。
Meta第二轮裁人波及万人，苹果推延发放奖金
硅谷的裁人、降薪潮远未完毕。
3 月 14 日周二，Meta 和苹果纷纷宣告最新的人事政策。
周二，Meta 的第二轮裁人终于确定，将裁人大约一万人，一起还将关闭 5000 个额定空缺职位，以求节省开支、进步效率。这是 Meta 在六个月时刻里的第二轮重大裁人举动。
Meta 的首席履行官马克扎克伯格周二在声明中表明，该公司的方针是经过取消办理层的多层级结构来让公司变得更加扁平化。
周二，Meta 高开高走，当时股价上涨 5.93% ，报 191.62 美元。
上个月，有媒体报导称，Meta 还一向致力于扁平化其组织，向办理人员供给买断计划，并裁减其以为不必要的整个团队，此举仍在最终敲定中，可能会影响数千名职工。
知情人士称，Meta 行将到来的新一轮裁人是由财政方针推进的，与公司“扁平化”没有直接关系。知情人士说，Meta 现已看到广告收入放缓，并将重点转移到元宇宙渠道，公司高层一向在要求董事和副总裁列出能够辞退的职工名单。
据知情人士泄漏，这一阶段的裁人最快可能会在本周完结。一位知情人士说，那些正在拟定裁人计划的人期望在首席履行官扎克伯格为他的第三个孩子休育儿假之前准备好，因而这次裁人的速度可能会非常快。
App Store 的定价机制晋级现已扩展至一切购买类型
在 12 月，咱们宣告对 App Store 进行面世至今最全面的定价机制晋级，其间包含新增价格点和按店面办理定价的全新东西。即日起，这些晋级和新价格适用于一切类型的 App 和 App 内购买项目，包含付费 App 和一次性 App 内购买项目。
更为灵活的价格点。可在 900 个价格点中挑选定价 — 比此前付费 App 和一次性 App 内购买项目的可选价格点数量增加了近 9 倍。这些选项也供给了更高的定价灵活度，价格点按价格区间逐步递增 (如在 RMB 10 以下每档相差 RMB 0.5；RMB 10 到 RMB 200 之间每档相差 RMB 1 等)。
增强的全球定价机制。全球均衡价格遵从了各个国家或区域最常见的定价办法。选用全球均衡价格，你能够供给更适用于当地顾客的定价。
依据基准价格供给全球定价办法。针对付费 App 和一次性 App 内购买项目，指定你了解的国家或区域，以之为根底为其他 174 个国家或区域的店面以及 43 种货币生成全球均衡价格。你为这个基准店面设定的价格，Apple 不会依据税款或外汇改变进行调整。此外，你也能够按个人喜好为每个店面自行设定价格。
为上架产品供给区域性定价计划。针对不同国家和区域的店面决议 App 内购买项目 (包含订阅) 的出售规模，因而你能够为各个商场分发定制的内容和服务。
准备好迎接行将在 5 月推出的增强全球定价机制 App Store 的全球均衡价格东西为你供给了一种简略便捷的办法来办理国际商场的定价。在 2023 年 5 月 9 日，在一切 175 个 App Store 店面中的现有 App 和一次性 App 内购买项目的价格都将更新，以充分利用此次全新的增强全球定价机制。更新后的价格将依据金融数据组织供给的揭露汇率信息做调整，在全球规模内与你为基准店面设定的价格保持平衡。这些价格点将跟随各个国家或区域最常见的定价办法，让价格更适用于当地顾客。
你立刻就能运用 App Store Connect 或 App Store Connect API 更新你的当时定价，以充分利用此次全新晋级。在 5 月 9 日，假如你的现有 App 和一次性 App 内购买项目还没有完结价格更新，Apple 将以产品当时在美国店面的价格为根底，为它们生成相应的更新价格。假如你期望以其他价格作为根底，现在可经过更新基准店面的国家或区域，为 App 或 App 内购买项目挑选新的基准店面。你还能够挑选手动办理所选店面中的价格，而不运用均衡的价格。
提案
经过检查的提案
SE-0382 Expression Macros 提案经过检查。该提案已在 二十期周报 正在检查的提案模块做了详细介绍。
SE-0388 增加 Async[Throwing]Stream.makeStream 办法 提案经过检查。该提案已在 二十四期周报 正在检查的提案模块做了详细介绍。
SE-0389 Attached Macros 提案经过检查。该提案已在 二十四期周报 正在检查的提案模块做了详细介绍。
正在检查的提案
SE-0392 自界说 Actor 履行器 提案正在检查。
该提案介绍了一种用于自界说 actor 履行程序的根本机制。经过供给履行者的实例，参加者能够影响他们将在什么地方履行正在运转的一些使命。
注意： 该提案仅界说了一组 API 来自界说 actor 履行器，其他类型的履行器控制超出了该特定提案的规模。
Swift论坛
- 提议Observation（修订）
介绍
制作呼应式应用程序一般需求能够在根底数据发生改变时更新演示文稿。 调查者形式答应一个主题维护一个调查者列表，并通知他们特定的或一般的状态改变。 这具有不直接将方针耦合在一同并答应在潜在的多个调查者之间隐式散布更新的长处。 可调查方针不需求关于其调查者的特定信息。
这种规划形式是许多言语都走过的一条很好的路途，Swift 有时机供给一个健壮的、类型安全的和高功用的完成。 该提议界说了什么是可调查引证、调查者需求遵守什么以及类型与其调查者之间的联络。
动机
Swift 中现已有一些调查机制。 其间包含键值调查 (KVO) 和 ObservableObject，但它们中的每一个都有局限性。 KVO 只能与 NSObject 子孙一同运用，而 ObservableObject 需求运用 Combine，它仅限于 Darwin 渠道而且不运用当时的 Swift 并发功用。 经过从这些现有体系中吸取经验，咱们能够构建一个更遍及有用的功用，适用于一切 Swift 引证类型，而不仅仅是那些继承自 NSObject 的引证类型，并使其跨渠道作业，并具有 async/await 等言语功用的优势。
现有体系取得了许多正确的行为和特征。 可是，有许多范畴能够在安全性、功用和表现力之间供给更好的平衡。 例如，将相关的更改分组到一个独立的业务中是一项常见的使命，可是这在运用 Combine 时很复杂而且在运用 KVO 时不受支撑。 在实践中，调查者想要拜访买卖，并能够指定怎么解说买卖。
注释阐明晰可调查的内容，但也可能很麻烦。 例如，Combine 不仅要求类型契合 ObservableObject，还要求被调查的每个特点都标记为 @Published。 此外，无法直接调查核算出的特点。 实际上，在可调查的类型中具有非调查字段并不常见。
在整个文档中，对 KVO 和 Combine 的引证将阐明哪些功用是有益的而且能够合并到新办法中，以及能够以更稳健的办法解决哪些缺点。
现有技术
KVO
Objective-C 中的键值调查很好地服务于该模型，但仅限于从 NSObject 继承的类层次结构。 API 仅供给事情拦截，这意味着更改通知坐落 willSet 和 didSet 事情之间。 KVO 在事情粒度方面具有很大的灵活性，但缺少可组合性。 KVO 调查者还必须继承自 NSObject，并依赖 Objective-C 运转时来跟踪发生的改变。 尽管 KVO 的接口现已更新为运用更现代的 Swift 强类型键途径，但在底层它的事情依然是字符串类型的。
Combine
Combine 的 ObservableObject 在 willSet/didSet 事情的前缘产生改变，一切的值都在值被设置之前传递。 尽管这很好地服务于 SwiftUI，但它对非 SwiftUI 的运用有约束，而且关于第一次遇到该约束的开发人员来说可能会感到惊讶。 ObservableObject 还要求将一切调查到的特点标记为 @Published 以与更改事情进行交互。 在大多数情况下，这一要求适用于每一个独自的特点，对开发者来说变得多余； 编写契合 ObservableObject 类型的人必须重复（几乎没有真正取得清晰度）注释每个特点。 最终，这会导致对参加项目或不参加项目的含义疲惫。
咱们提出了一个名为 Observation 的新规范库模块，其间包含完成这种形式的协议、类型和宏。
根本上，一个类型能够简略地经过运用 @Observable 宏注解将自己声明为可调查的：
@Observable public final class MyObject {
public var someProperty: String = ""
public var someOtherProperty = 0
fileprivate var somePrivateProperty = 1
}
@Observable 宏声明并完成与 Observable 协议的共同性，该协议包含一组处理调查的扩展办法。 在最简略的情况下，客户端能够运用 changes(for:) 办法来调查给定实例的特定特点的改变。
func processChanges(_ object: MyObject) async {
for await value in object.values(for: \.someProperty) {
print(value)
}
}
这答应 Observable 类型的用户将特定值的更改或整个实例作为更改事情的异步序列进行调查。 changes(for:) 办法供给类型安全，因为它只供给对一个特定特点的更改。
object.someProperty = "hello"
// prints "hello" in the awaiting loop
object.someOtherProperty += 1
// nothing is printed
可调查方针还能够供给分组到业务中的更改，这些业务合并了在暂停点之间进行的任何更改。 默认情况下，买卖会独自交付给您供给的参加者或首要参加者。
func processTransactions(_ object: MyObject) async {
for await change in objects.changes(for: [\.someProperty, \.someOtherProperty]) {
print(myObject.someProperty, myObject.someOtherProperty)
}
}
与 ObservableObject 和 @Published 不同，@Observable 类型的特点不需求独自标记为可调查。 相反，一切存储的特点都是隐式可调查的。
关于只读核算特点，作者能够增加 static dependencies(of:) 办法来声明额定的要害途径作为他们调查的一部分。 这相似于 KVO 用来供给对键途径有影响的附加键途径的机制。
extension MyObject {
var someComputedProperty: Int {
somePrivateProperty + someOtherProperty
}
nonisolated static func dependencies(
of keyPath: PartialKeyPath<Self>
) -> TrackedProperties<Self> {
switch keyPath {
case \.someComputedProperty:
return [\.somePrivateProperty, \.someOtherProperty]
default:
return [keyPath]
}
}
}
因为一切对调查改变的拜访都是经过要害途径进行的，因而 public 和 private 等可见性要害字决议了能够调查到什么，不能调查到什么。 与 KVO 不同，这意味着只能调查到在特定规模内可拜访的成员。 这一现实反映在规划中，其间业务表明为 TrackedProperties 实例，它答应查询更改的键途径，但不能查询它们的迭代。
- 提议在 Swift 6 中省掉 some
介绍
现在，在类型方位中编写一般协议称号的默认值是 any，但其间许多隐含的 any 用法能够替换为 some，从而为它们供给更多类型信息，一起仍能正确运转。 该提议翻转了默认值，以便在编写一般协议时，类型将默以为 some 而不是 any。 使默认值 some 确保固定的底层类型，它保留与底层类型的静态类型关系，使您能够彻底拜访运用 Self 和相关类型的协议要求和扩展办法。
动机
一段时刻以来，Swift 一向致力于改善泛型的 UI，在 Swift 5.1 中引入了 some 要害字来表明不透明类型——特定详细类型的笼统类型占位符——它在 Swift 5.7 类型中扩展到参数，这样：
func foo<T>(_ bar: T) where T: Equatable { }
// is equivalent to
func foo(_ bar: some T) { }
Swift 5.6 引入了 explicit any，这在 Swift 6 言语形式中是必需的，以确保挑选类型擦除而不是运用类型参数是明确和深思熟虑的。 引入运用显式 any 的要求并鼓励默认编写一些，这为将一些作为一般协议称号的默认值供给了时机。
通用代码现已在比您幻想的更多的地方得到了简化。 以协议扩展为例。 要编写适用于任何契合协议的详细类型的通用代码，您只需编写扩展要害字和一般协议称号。 在此示例中，咱们运用 Collection 协议：
// What you write to extend all concrete types conforming to 'Collection':
extension Collection { ... }
在通用代码中，通用签名表明通用参数和对这些参数的任何要求。 在协议扩展的情况下，有一个名为 Self 的隐式类型参数和单一共同性要求 Self: Collection 由编译器增加，而不需求您编写。 这答应您从契合要求的 Self 类型上的 Collection 协议拜访一切协议要求、相关类型和其他扩展办法。
当存在不需求运用 where 子句内化泛型签名的垫脚石时，程序员学习泛型编程会容易得多。 程序员能够运用更直接、更直观的语法来表达同一事物。 Swift 6 能够将相同的准则应用于其他上下文中的一般协议称号。 这种做法关于学习 Swift 的初学者来说可能是无价的，它消除了在向代码中增加协议时比较某些和任何之间的权衡的心理担负。 初学者不需求在运用 some 仍是 any 之间做出决议，推延彻底理解语义差异的需求，直到绝对有必要在两者之间进行挑选。 即使您不是初学者，一些默认设置依然能够经过使代码更简洁来进步代码的可读性。
- 评论并发功用真的很差以及怎么优化代码
内容大概：
咱们正在对各种编程言语的并发性进行比较，并运用 Swift 完成一维热方程求解器。 与 Python、Rust 和 C++ 相比，swift 的功用看起来不是很好。 首要，代码最多只能扩展到三个内核，见下文
中心，总时刻
10,2111.423936009407 8,2189.256893992424 5,1967.6182420253754 4,1929.6173659563065 2,3097.796007990837 1,4388.57520699501
但是，每秒的浮点运算相当低，例如在三个内核上咱们每秒能够进行 500 次浮点运算。 与其他言语相比，这并不多。
所以，已然咱们想发布结果，我想寻求一些协助，因为我以为咱们在 Swift 中的完成并不好。
Vote最多的回答：
这种问题关于简略的并发或多线程来说一般是一个非常糟糕的情况：
您的作业集太大。 在 2 * 10000000 * MemoryLayout(Double).size，你有一个 160MB 的作业集，它不合适缓存，所以你实际上遭到内存速度的约束，而不是核算速度，这 与额定资源的扩展几乎不一样。
假如你用较小的作业集解决了这个问题，你就会被数据局部性所困扰。 您的确期望将每个 worker 固定到数据的固定部分，因而它会在下一个时刻步坐落与 worker 相关的缓存中。
-
评论@State 没有正确初始化
-
评论Swift 中的轻量级 MVVMLight 架构形式
-
评论协议类型里的 Generic“where” 失效
-
评论怎么运用
defer模仿 RAII
内容大概
Swift 的 defer 句子具有很好的模仿 C++ 的资源获取即初始化行为的能力，因为 ARC，咱们无法做到这一点。 假如您正在运用 UnsafeMutablePointer 经过确保在退出规模时正确收拾资源来履行某些操作，这可能会很便利：
import Foundation
class FileHandler {
private var file: UnsafeMutablePointer<FILE>?
init?(filePath: String) {
file = fopen(filePath, "r")
guard file != nil else {
print("Error: Unable to open the file.")
return nil
}
}
deinit {
if file != nil {
fclose(file)
}
}
func readAndProcessFile() {
defer {
if file != nil {
fclose(file)
file = nil
}
}
// Read and process the file
}
}
if let fileHandler = FileHandler(filePath: "path/to/your/file.txt") {
fileHandler.readAndProcessFile()
}
在这个比如中，咱们有一个办理文件的 FileHandler 类。 当调用 readAndProcessFile 办法时，咱们运用 defer 块来确保在办法退出时关闭文件，无论它是正常退出仍是因为过错退出。 这相似于 C++ 中的 RAII 概念，其间在方针超出规模时履行资源收拾。
当然，这不是 RAII 的 1:1，但它显现了一种能够运用 defer 来完成相似效果的办法。
引荐博文
Swift 中怎么运用 XCTest 框架进行功用测验
摘要： 本文介绍了怎么在 Swift 中运用 XCTest 框架进行功用测验，并经过 measure 函数来测量应用程序中特定代码途径的功用。
两个新的开源 Swift 库：Swift Certificates 和 Swift ASN.1
摘要： 这篇文章介绍了两个新的开源 Swift 库：Swift Certificates 和 Swift ASN.1。这两个库共同供给了更快、更安全的 X.509 证书完成，X.509 证书是支撑 TLS 安全的要害技术之一。文章解说了X.509 证书和 ASN.1 格式的概念，和为什么需求构建一个 ASN.1 库以支撑完好的 X.509 库，并介绍了 Swift ASN.1 和 Swift Certificates 的功用和方针。 Swift Certificates 现在能够解析大多数契合 RFC 5280 规范和 Web PKI 中运用的 X.509 证书，支撑插件式 X.509 验证策略和 OCSP 分辨率。短期方针是运用 Swift Certificates 替换 swift-nio-ssl 中的 BoringSSL 完成，以供给更高功用和更好的内存安全性。
云音乐 Swift 混编 Module 化实践
摘要： 文章介绍了网易云音乐 iOS App 在支撑 Swift 混编过程中，Module 化阶段的剖析与实践以及在实践过程中可能会遇到各种不知道问题。
论题评论
文心一言挑战ChatGPT，谁更胜一筹？
- 文心一言
- ChatGPT
- 不分伯仲
欢迎在文末留言参加评论。
关于咱们
Swift社区是由 Swift 爱好者共同维护的公益组织，咱们在国内以微信大众号的运营为主，咱们会共享以 Swift实战、SwiftUl、Swift根底为中心的技术内容，也收拾收集优异的学习材料。
特别感谢 Swift社区 修改部的每一位修改，感谢大家的辛苦付出，为 Swift社区 供给优质内容，为 Swift 言语的发展贡献自己的力量。
本文正在参加「金石计划」
