├── .DS_Store
├── .gitignore
├── LICENSE
├── README.md
├── SwiftWeekly
├── .DS_Store
├── SwiftWeekly82_process.md
├── SwiftWeekly88_process.md
├── SwiftWeekly_1.md
├── SwiftWeekly_10.md
├── SwiftWeekly_11.md
├── SwiftWeekly_12.md
├── SwiftWeekly_13.md
├── SwiftWeekly_14.md
├── SwiftWeekly_15.md
├── SwiftWeekly_16.md
├── SwiftWeekly_17.md
├── SwiftWeekly_18.md
├── SwiftWeekly_19.md
├── SwiftWeekly_2.md
├── SwiftWeekly_20.md
├── SwiftWeekly_21.md
├── SwiftWeekly_22.md
├── SwiftWeekly_23.md
├── SwiftWeekly_24.md
├── SwiftWeekly_25.md
├── SwiftWeekly_26.md
├── SwiftWeekly_27.md
├── SwiftWeekly_28.md
├── SwiftWeekly_29.md
├── SwiftWeekly_3.md
├── SwiftWeekly_30.md
├── SwiftWeekly_31.md
├── SwiftWeekly_32.md
├── SwiftWeekly_33.md
├── SwiftWeekly_34.md
├── SwiftWeekly_35.md
├── SwiftWeekly_36.md
├── SwiftWeekly_37.md
├── SwiftWeekly_38.md
├── SwiftWeekly_39.md
├── SwiftWeekly_4.md
├── SwiftWeekly_40.md
├── SwiftWeekly_41.md
├── SwiftWeekly_42.md
├── SwiftWeekly_43.md
├── SwiftWeekly_44.md
├── SwiftWeekly_45.md
├── SwiftWeekly_46.md
├── SwiftWeekly_47.md
├── SwiftWeekly_48.md
├── SwiftWeekly_49.md
├── SwiftWeekly_5.md
├── SwiftWeekly_50.md
├── SwiftWeekly_51.md
├── SwiftWeekly_52.md
├── SwiftWeekly_53.md
├── SwiftWeekly_54.md
├── SwiftWeekly_55.md
├── SwiftWeekly_56.md
├── SwiftWeekly_57.md
├── SwiftWeekly_58.md
├── SwiftWeekly_59.md
├── SwiftWeekly_6.md
├── SwiftWeekly_60.md
├── SwiftWeekly_61.md
├── SwiftWeekly_62.md
├── SwiftWeekly_63.md
├── SwiftWeekly_64.md
├── SwiftWeekly_65.md
├── SwiftWeekly_66.md
├── SwiftWeekly_67.md
├── SwiftWeekly_68.md
├── SwiftWeekly_69.md
├── SwiftWeekly_7.md
├── SwiftWeekly_70.md
├── SwiftWeekly_71.md
├── SwiftWeekly_72.md
├── SwiftWeekly_73.md
├── SwiftWeekly_74.md
├── SwiftWeekly_75.md
├── SwiftWeekly_76.md
├── SwiftWeekly_77.md
├── SwiftWeekly_78.md
├── SwiftWeekly_79_process.md
├── SwiftWeekly_8.md
├── SwiftWeekly_80_process.md
├── SwiftWeekly_81_process.md
├── SwiftWeekly_83_process.md
├── SwiftWeekly_84_process.md
├── SwiftWeekly_85_process.md
├── SwiftWeekly_86_process.md
├── SwiftWeekly_87_process.md
├── SwiftWeekly_9.md
└── 图片.jpeg
└── res
└── 21-GitHub-App.md
/.DS_Store:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/SwiftCommunityRes/SwiftWeekly/ff06500903358fa4b4942368375dd51a01cdcbff/.DS_Store
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | # Xcode
2 | #
3 | # gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore
4 |
5 | ## User settings
6 | xcuserdata/
7 |
8 | ## compatibility with Xcode 8 and earlier (ignoring not required starting Xcode 9)
9 | *.xcscmblueprint
10 | *.xccheckout
11 |
12 | ## compatibility with Xcode 3 and earlier (ignoring not required starting Xcode 4)
13 | build/
14 | DerivedData/
15 | *.moved-aside
16 | *.pbxuser
17 | !default.pbxuser
18 | *.mode1v3
19 | !default.mode1v3
20 | *.mode2v3
21 | !default.mode2v3
22 | *.perspectivev3
23 | !default.perspectivev3
24 |
25 | ## Obj-C/Swift specific
26 | *.hmap
27 |
28 | ## App packaging
29 | *.ipa
30 | *.dSYM.zip
31 | *.dSYM
32 |
33 | ## Playgrounds
34 | timeline.xctimeline
35 | playground.xcworkspace
36 |
37 | # Swift Package Manager
38 | #
39 | # Add this line if you want to avoid checking in source code from Swift Package Manager dependencies.
40 | # Packages/
41 | # Package.pins
42 | # Package.resolved
43 | # *.xcodeproj
44 | #
45 | # Xcode automatically generates this directory with a .xcworkspacedata file and xcuserdata
46 | # hence it is not needed unless you have added a package configuration file to your project
47 | # .swiftpm
48 |
49 | .build/
50 |
51 | # CocoaPods
52 | #
53 | # We recommend against adding the Pods directory to your .gitignore. However
54 | # you should judge for yourself, the pros and cons are mentioned at:
55 | # https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
56 | #
57 | # Pods/
58 | #
59 | # Add this line if you want to avoid checking in source code from the Xcode workspace
60 | # *.xcworkspace
61 |
62 | # Carthage
63 | #
64 | # Add this line if you want to avoid checking in source code from Carthage dependencies.
65 | # Carthage/Checkouts
66 |
67 | Carthage/Build/
68 |
69 | # Accio dependency management
70 | Dependencies/
71 | .accio/
72 |
73 | # fastlane
74 | #
75 | # It is recommended to not store the screenshots in the git repo.
76 | # Instead, use fastlane to re-generate the screenshots whenever they are needed.
77 | # For more information about the recommended setup visit:
78 | # https://docs.fastlane.tools/best-practices/source-control/#source-control
79 |
80 | fastlane/report.xml
81 | fastlane/Preview.html
82 | fastlane/screenshots/**/*.png
83 | fastlane/test_output
84 |
85 | # Code Injection
86 | #
87 | # After new code Injection tools there's a generated folder /iOSInjectionProject
88 | # https://github.com/johnno1962/injectionforxcode
89 |
90 | iOSInjectionProject/
91 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2021 SwiftCommunityRes
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | [](https://github.com/SwiftCommunityRes/SwiftWeekly/releases.atom)
2 |
3 | 
4 |
5 | *一个关注 [Swift.org](https://swift.org) 动态，由社区驱动的每周时事通讯*
6 |
7 | ## 往期回顾
8 |
9 | 周报内容模块分为：**新闻**、**提案**、**Swift论坛**、**推荐博文**。初期计划每两周发布一期，每个模块还在调整磨合期。各位读者如果有好的提议，欢迎提 Issues。
10 |
11 | Swift 周报 第五十二期
12 | Swift 周报 第五十一期
13 | Swift 周报 第五十期
14 |
15 |
16 | 点击查看更多内容
17 | Swift 周报 第五十期
18 | Swift 周报 第四十九期
19 | Swift 周报 第四十八期
20 | Swift 周报 第四十七期
21 | Swift 周报 第四十六期
22 | Swift 周报 第四十五期
23 | Swift 周报 第四十四期
24 | Swift 周报 第四十三期
25 | Swift 周报 第四十二期
26 | Swift 周报 第四十一期
27 | Swift 周报 第四十期
28 | Swift 周报 第三十九期
29 | Swift 周报 第三十八期
30 | Swift 周报 第三十七期
31 | Swift 周报 第三十六期
32 | Swift 周报 第三十五期
33 | Swift 周报 第三十四期
34 | Swift 周报 第三十三期
35 | Swift 周报 第三十二期
36 | Swift 周报 第三十一期
37 | Swift 周报 第三十期
38 | Swift 周报 第二十九期
39 | Swift 周报 第二十八期
40 | Swift 周报 第二十七期
41 | Swift 周报 第二十六期
42 | Swift 周报 第二十五期
43 | Swift 周报 第二十四期
44 | Swift 周报 第二十三期
45 | Swift 周报 第二十二期
46 | Swift 周报 第二十一期
47 | Swift 周报 第二十期
48 | Swift 周报 第十九期
49 | Swift 周报 第十八期
50 | Swift 周报 第十七期
51 | Swift 周报 第十六期
52 | Swift 周报 第十五期
53 | Swift 周报 第十四期
54 | Swift 周报 第十三期
55 | Swift 周报 第十二期
56 | Swift 周报 第十一期
57 | Swift 周报 第十期
58 | Swift 周报 第九期
59 | Swift 周报 第八期
60 | Swift 周报 第七期
61 | Swift 周报 第六期
62 | Swift 周报 第五期
63 | Swift 周报 第四期
64 | Swift 周报 第三期
65 | Swift 周报 第二期
66 | Swift 周报 第一期
67 |
68 |
69 | ## 参与编辑
70 |
71 | Swift 周报开源，欢迎提交 issue，投稿或推荐内容，目前计划每两周周一发布。
72 |
73 | >**招募:** 欢迎志同道合的朋友一起加入周报整理，不仅可以学习各种技巧和知识，还能积累自己的技术影响力
74 |
75 | ## 平台发布
76 |
77 | 公众号：Swift社区
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly88_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_1.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | 从本周开始，我们 Swift 社区公众号将开始与 SwiftWeekly 合作更新关于 Swift 社区最新的进展与动向。让我们乘着社区的风帆，一起荡起双桨，让 Swift 成为世界上最好的语言。
4 |
5 | ## 播客
6 |
7 | 在 Swift by Sundell 播客的[第 103 期](https://www.swiftbysundell.com/podcast/103/ "Swift by Sundell 第 103 期")中，SwiftLee 的创建者 [Antoine van der Lee](https://twitter.com/twannl "Antoine van der Lee") 加入了 [John Sundell](https://twitter.com/johnsundell "John Sundell")。
8 |
9 | 他们从新的 concurrency 系统到 convenience 特性以及各种改进等方向讨论了 Swift 5.5 新引入的一部分功能。
10 |
11 | ## 新闻和社区
12 |
13 | Xcode 各版本的 [最低要求和支持的 SDK](https://developer.apple.com/cn/support/xcode/ "最低要求和支持的 SDK")
14 |
15 | [Antoine van der Lee](https://twitter.com/twannl "Antoine van der Lee") 写了一篇博文，[探讨在 Swift 中解包或 throw 的解决方案](https://www.avanderlee.com/swift/unwrap-or-throw/ "Unwrap or throw: Exploring solutions in Swift")。
16 |
17 | [Leonardo Maia Pugliese](https://twitter.com/Leo_Pugliese "Leonardo Maia Pugliese") 写了一篇关于[如何在 Swift 中使用 @available 进行 API 约束](https://holyswift.app/how-to-do-apis-constraints-with-available-in-swift "How to do APIs constraints with @Available in Swift")的博客文章。
18 |
19 | [John Sundell](https://twitter.com/johnsundell "John Sundell") 写了一篇文章解释了如何[在 switch 语句中使用 @unknown default](https://www.swiftbysundell.com/articles/using-an-unknown-default-case-within-a-switch-statement/ "Using ‘@unknown default’ within switch statements")。
20 |
21 | [Bas Broek](https://twitter.com/basthomas "Bas Broek") 写了一篇博文，探讨如何在 Swift 中[弃用 Workarounds](https://www.basbroek.nl/deprecating-workarounds "Deprecating Workarounds")。
22 |
23 | ## 正在审查的提案
24 |
25 | [SE-0321](https://github.com/apple/swift-evolution/blob/main/proposals/0321-package-registry-publish.md "SE-0321"): Package Registry Service - Publish Endpoint 正在[审查中](https://forums.swift.org/t/se-0321-package-registry-service-publish-endpoint/51286 "Package Registry Service - Publish Endpoint")
26 |
27 | 软件包注册表负责确定哪些软件包版本可提供给消费者使用。
28 |
29 | 目前，软件包版本的可用性由 `out-of-band` 流程决定。例如，注册表可以查询公共 Swift 软件包的索引，并为每个标签提供具有有效版本号的版本。
30 |
31 | 拥有发布新版本到软件包注册表的标准端点将增强维护者分发其软件的能力，并促进服务提供商之间的互操作性。
32 |
33 | ## Swift 论坛
34 |
35 | [Dimitri Racordon](https://forums.swift.org/categories "Dimitri Racordon") 提出了一个[用私有字段实现协议的想法](https://forums.swift.org/t/pitch-protocols-with-private-fields/51209 "Protocols with private fields")。
36 |
37 | 在协议中，所有字段（`properties` 和 `methods`）都将获得符合条件类型的访问可见性。例如，符合具有公共类型的协议将提示其所有要求都是公共的。
38 |
39 | [Evan Wilde](https://forums.swift.org/categories "Evan Wilde") 提出了一项[重新审视 async main 语义](https://forums.swift.org/t/pitch-revisit-the-semantics-of-async-main/51254 "Revisit the semantics of async main")的提案。
40 |
41 | * main 函数应该同步运行到第一个暂停点
42 | * main 函数应该在 `main actor` 上运行
43 | * MainActor 应该为默认的 `runloop` 行为提供用户指定的替代方案。
44 | * main 任务应该从 `getCurrentThreadPriority` 拉取优先级，而不是 `hard-coded` 默认优先级
45 |
46 | [Anders Bertelrud](https://forums.swift.org/u/abertelrud "Anders Bertelrud") 提议修改 SE-0303：插件 API，使用 @main 作为插件入口点。
47 |
48 | 我想提议修改 `SE-0303`，`SwiftPM` 插件使用 `@main` 作为入口点，而不是 `top-level` 作为入口点。 虽然这样做有点冗长，但是可以为每种插件定制入口点，并且还可以更加清楚地说明每个插件的输入和预期输出是什么。
49 |
50 | [Jeremy Saklad](https://forums.swift.org/u/saklad5 "Jeremy Saklad") 提出了一项提案，该提案将[允许使用具体的相关协议类型](https://forums.swift.org/t/allow-use-of-concrete-associated-type-of-protocols/51277 "Allow use of concrete associated type of protocols")。
51 |
52 | [Karoy Lorentey](https://twitter.com/lorentey "Karoy Lorentey") 发布了 [Swift Collections 1.0 版](https://forums.swift.org/t/announcement-planning-for-swift-collections-v1-0/51321 "Planning for Swift Collections v1.0")。
53 |
54 | [Konrad ktoso Malawski](https://forums.swift.org/u/ktoso "Konrad ktoso Malawski") 发布了 Swift Server Workgroup [2021 年 8 月 4 日的会议记录](https://forums.swift.org/t/august-4th-2021/51315 "August 4th 2021")。
55 |
56 | [Doug Gregor](https://twitter.com/dgregor79 "Doug Gregor") 提出了 [在 Sendable 检查中实施 Staging](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341 "Staging in Sendable checking") 的提案。
57 |
58 | `SE-0302` 引入了 Sendable 协议，该协议明确地指出哪些类型的值可以安全地跨过 `actors` 进行复制。通俗的讲，就是拷贝的值和原始值可以同时在上下文使用。
59 |
60 | Sendable 检查在所有 Swift 代码中应用，消除了由 `shared mutable state` 引起的大量数据竞争。Swift 5.5 没有完全实现 Sendable 检查，因为这样做会导致太多的编译器 `errors` 和 `diagnostics`，从而导致该功能不可用。
61 |
62 | 我认为可以逐步采用 Sendable 检查来提高数据竞争的安全性。我们提出了两个想法分段完成 Sendable 检查:
63 |
64 | * 增量采用并发并且引入更多的 Sendable 检查。
65 | * 不能让用户模块之外的 Sendable 问题阻挡进度，防止过度的注释
66 |
67 | [Aura Lily Vulcano](https://forums.swift.org/categories "Aura Lily Vulcano") 推荐了一个 [Swift 默认提供的新模块](https://forums.swift.org/t/pitch-the-cstdlib-module/51373 "The CStdlib module")。
68 |
69 | 该模块将重新导出包含当前平台的 `POSIX` 或类似 `POSIX` 的 C 标准库的正确模块（如果有的话）。
70 |
71 | 默认情况该模块不会被导入，但是允许 “reasonably cross-platform” 代码，以避免使用冗长的 `#if canImport(…)` 链来访问所有的标准库，因为它们在不同的操作系统上有不同的名称。
72 |
73 | 例如，模块可以命名为 CStdlib。
74 |
75 | Robert Widmann（[@CodaFi_](https://twitter.com/CodaFi_ "CodaFi_")）提出了一个关于[开始可变参数泛型](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467 "The Start of Variadic Generics")的想法。
76 |
77 | 作为改进泛型系统的人体工程学的一部分，以及为使用 tuples 抽象提供更好的支持，我想用 surface syntax 和 preliminary semantics 来实现这个想法。 由于这是一个很大的主题领域，对语言和后续提案的方向都有很大影响，因此你的反馈在此阶段对于塑造此功能集的方向至关重要。
78 |
79 | 我要感谢 **Alejandro Alonso**, **Doug Gregor** 和 **Slava Pestov**，感谢他们为我在这个问题上的思考奠定了基础。
80 |
81 | 可以在这里看到原文的链接 [TypeSequences.md · GitHub](https://gist.github.com/CodaFi/a461aca155b16cd4d05a2635e7d7a361 "TypeSequences.md · GitHub")
82 |
83 | ## 关于我们
84 |
85 | 公众号是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。欢迎关注公众号：**Swift社区**，后台点击进群，联系我们获取更多内容。
86 |
87 |
88 |
89 |
90 | 感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。周报仓库：https://github.com/SwiftCommunityRes
91 |
92 | 后续还会翻译大量资料到我们公众号，有感兴趣的朋友，可以加入我们，扫码添加微信
93 |
94 | 
95 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_10.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | 前几期周报内容是同步翻译的英文版周报，目前英文版停更，周报停滞半年多。经过多次讨论，我们决定**重启周报**，分模块整理内容同步给大家。
4 |
5 | 周报内容模块分为：**新闻**、**提案**、**Swift论坛**、**推荐博文**。初期计划每两周发布一期，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 昨日的生活与工作是否也曾迷茫？对新技术渴望突破的心是否依旧执着？**Swift社区**，为你的技术栈添砖加瓦，你，准备好了吗？
8 |
9 | ## 新闻和社区
10 |
11 | ### 苹果先买后付服务被警告：破坏这一新兴行业的竞争
12 |
13 | 据英国《金融时报》7月27日报道，美国消费者金融保护局罗希特·乔普拉向硅谷发出警告。大型科技公司进入“先买后付”贷款业务会破坏这一新兴行业的竞争，他还对客户数据的使用提出了质疑。此前6月6日苹果公司在年度开发者大会上推出“先买后付”的`“Apple Pay Later”`服务，允许用户6周内分4期付款，期间不产生利息等其他费用。（via 泰山财经）
14 |
15 | ### 与 App Store 专家会面交流
16 |
17 | 准备好与专家在线交流探讨，了解如何充分利用 `App Store` 的功能。探索如何吸引新顾客、测试营销策略、添加订阅等等。在整个 8 月，苹果官方将在多个时区以多种语言进行实时演讲和答疑。如果您也是苹果开发者的话，最近肯定收到了相关的邮件邀请吧，不知道您是否参加了本次会面交流呢？（Apple Developer Program）
18 |
19 | ### 即将从 XML Feed 过渡到 App Store Connect API
20 |
21 | `App Store Connect REST API` 让您可以跨各种开发者工具自定义任务并实现任务自动化，使工作流程更灵活、更高效。从 **2022 年 11 月**开始，您将需要使用此 API 来代替 `XML Feed`，从而实现对 App 内购买项目、订阅、元数据和 App 定价的自动化管理。XML Feed 将继续为现有的 `Game Center` 管理功能提供支持。（Apple Developer News）
22 |
23 | ### 新功能 RoomPlan
24 |
25 | 使用 [RoomPlan](https://developer.apple.com/augmented-reality/roomplan/ "Introducing RoomPlan") 创建房间的 3D 户型图，包括家具的尺寸和类型等关键特征。这个是由 ARKit 提供支持的全新 Swift API 能够利用 iPhone 和 iPad 上的摄像头和激光雷达扫描仪将现实环境带入您的 App 中。
26 |
27 | 
28 |
29 | 使用详情可以观看 WWDC22 中的 [使用 RoomPlan 创建参数 3D 房间扫描](https://developer.apple.com/videos/play/wwdc2022/10127/ "Create parametric 3D room scans with RoomPlan")
30 |
31 | ### 立即注册 WWDC22 实验室和聊天室
32 |
33 | [注册实验室和线上聊天室](https://developer.apple.com/news/?id=kvwb7ph4 "Sign up now for WWDC22 labs and lounges")，即可在一整周内与 Apple 工程师、设计师和专家在线交流。
34 |
35 | 
36 |
37 | ### 已推出 Xcode 14 Beta 版
38 |
39 | 包含了适用于所有 Apple 平台 SDK 的 `Xcode 14 Beta` 版现已推出。利用简洁且强大的 Swift 和 SwiftUI 以及全新的跨平台 App 体验，使用编辑器的增强功能更快捷地编写代码，并着手开始进行从 `Xcode Cloud` 到 `TestFlight` 以及 `App Store` 的测试和部署。
40 |
41 | [下载 Xcode 14 Beta 版](https://developer.apple.com/xcode/ "Xcode 14 Beta")
42 |
43 | ## 提案
44 |
45 | ### 通过的提案
46 |
47 | [SE-0352: 隐式开放的存在类型](https://github.com/apple/swift-evolution/blob/main/proposals/0352-implicit-open-existentials.md#introduction 'Implicitly Opened Existentials') **状态：Swift 5.7 已实现**
48 | Swift 中的存在类型允许存储一个特定类型为未知的值，且可能在运行时更改。被存储值的动态类型，我们称为**存在类型的底层类型**，仅由它遵循的协议集以及潜在的超类知道。尽管存在类型对于表达动态类型的值非常有用，但由于它们的动态性质，它们受到一定限制。最近的提议使[存在类型更加明确](https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md 'existential types more explicit')，以帮助开发人员理解这种动态性质，并通过消除一些限制[使存在类型更具表现力](https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md 'making existential types more expressive')。但是存在类型中的基本类型仍然存在，一旦你有一个存在类型的值，你就很难对其使用泛型。开发者通常会遇到 `protocol 'P' as a type cannot conform to itself` 这样的报错问题。
49 |
50 | **SE-0352: 隐式开放的存在类型** 已于 2022 年 5 月 18 日完成，核心团队已决定接受该提案。第二次审查的重点是关注向前兼容性，当一个调用唤起一个隐式开放的存在类型，必须被抹除类型以防止存在的动态类型内存泄漏到返回值中。当存在类型的表达能力增加，我们可能会有能力使用一个更具体的类型作为这一个调用的返回类型，这可能造成源中断。为了避免这种情况，该提案要求在调用中显式地作为任何 P 类型注释，其中当前可以表达的返回类型将丢弃对被类型擦除的原始关联类型的约束，如提案中的示例所示：
51 |
52 | ```swift
53 | protocol P {
54 | associatedtype A
55 | }
56 | protocol Q {
57 | associatedtype B: P where B.A == Int
58 | }
59 |
60 | func getP(_ p: T)
61 | func getBFromQ(_ q: T) -> T.B { ... }
62 |
63 | func eraseQAssoc(q: any Q) {
64 | let x = getBFromQ(q) // 错误，必须指定 "as any P" 由于缺少 T.B.A == Int 的约束
65 | let y = getBFromQ(q) as any P // 可以, 明确抛弃约束
66 | }
67 | ```
68 |
69 | [SE-0353: 受约束的存在类型](https://github.com/apple/swift-evolution/blob/main/proposals/0353-constrained-existential-types.md 'Constrained Existential Types') **状态：Swift 5.7 已实现**
70 | 存在类型弥补了 Swift 类型系统中的抽象能力。与泛型一样，它们使函数能够获取和返回多种可能的类型。与泛型参数类型不同，存在类型在作为输入传递给函数时不需要预先知道。此外，当从函数返回时，可以删除具体类型（隐藏在协议接口后面）。在这个领域出现了一系列活动，[SE-0309](https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md#covariant-erasure-for-associated-types 'SE-0309: unlock existential types for all protocols') 解除了对使用具有关联类型的协议作为存在类型的剩余限制，而 [SE-0346](https://github.com/apple/swift-evolution/blob/main/proposals/0346-light-weight-same-type-syntax.md 'SE-0346: light weight same type syntax') 为关联类型协议的轻量级约束语法铺平了道路。该提案直接基于这些想法，旨在在存在类型的上下文中重用轻量级关联类型约束的语法。
71 |
72 | ```swift
73 | any Collection
74 | ```
75 |
76 | [SE-0356: Swift 代码片段](https://github.com/apple/swift-evolution/blob/main/proposals/0356-swift-snippets.md 'Swift Snippets')
77 | 该提案描述了编写成为片段的新形式示例代码的约定。片段是简短的单文件示例，可以在 Swift 包中构建和运行，可以访问该包中的其他代码，并且可以以多种方式使用。
78 |
79 |
80 | ### 正在审查的提案
81 |
82 | [SE-0359: 构建时间常数值](https://github.com/apple/swift-evolution/blob/main/proposals/0359-build-time-constant-values.md 'Build-Time Constant Values') **状态：已接受**
83 | 构建时间常数值是一个 Swift 语言特性，要求在编译时知道某些值。这是通过属性、`@const`、约束属性和函数参数来实现的，以使其具有编译时可知的值。这些信息为未来更丰富的编译时特性奠定了基础，例如在编译时提取和验证值。
84 |
85 | [SE-0362: 即将到来的语言改进的逐渐采用](https://github.com/apple/swift-evolution/blob/main/proposals/0362-piecemeal-future-features.md 'Piecemeal adoption of upcoming language improvements') **状态：已接受**
86 | Swift 6 积累了许多对语言有源码兼容性影响的改进，从而在以前的语言模式（Swift 4.x 和 Swift 5.x）中默认情况下无法启用它们。这些改进已经在背后为 Swift 6 语言模式的 Swift 编译器中实现，但他们对于开发者是无法访问的，并将持续直到 Swift 6 作为一个可获得的语言模式。这有很多原因，为什么我们应该思考尽快提供这些改动。
87 |
88 | - 开发者希望很快从这些改进中受益，而不是等到 Swift 6 可用。
89 | - 向开发者提供这些改进比 Swift 6 提供更多体验优先级更高，如果有必要，允许我们针对 Swift 6 进一步调试它们。
90 | - 对于某些模块，所有在 Swift 6 中改动的总数或许会造成迁移繁重，并且在 Swift 4.x/5.x 中逐一采纳这些语言改动，可以使过渡期路径变得丝滑。
91 |
92 | 一些提案已经引入了定制解决方案来提供迁移路径：[SE-0337](https://github.com/apple/swift-evolution/blob/main/proposals/0337-support-incremental-migration-to-concurrency-checking.md 'support-incremental-migration-to-concurrency-checking') 添加了 `-warn-concurrency` 在 Swift 4.x/5.x 中启用与 `Sendable` 相关检查的警告。 [SE-0354](https://github.com/apple/swift-evolution/blob/main/proposals/0354-regex-literals.md 'regex-literals') 添加标志 `-enable-bare-slash-regex` 以启用原始 `/.../` 正则表达式语法。尽管它不是提案的一部分，但对 [SE-0335](https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md 'existential-any') 的讨论包括对编译器标志的请求，以在存在类型上要求使用 `any` 。这些都具有相同的风格，即选择现有的 Swift 4.x/5.x 代码进行改进，这些改进将出现在 Swift 6 中。
93 |
94 | 这个提议明确地包含了零碎的、有意采用的特性，这些特性在 Swift 6 之前出于源代码兼容性的原因而保留。它为逐步采用 Swift 6 特性建立了一条直接路径，以在 Swift 4.x/5.x 代码库中获得它们的优势，并顺利迁移到 Swift 6 语言模式。开发人员可以使用新的编译器标志 `-enable-upcoming-feature X` 为该模块启用名为 `X` 的特定功能，并且可以以这种方式指定多个功能。当开发人员移动到下一个主要语言版本时，该语言版本将隐含 `X` 并且编译器标志将被拒绝。这样，即将推出的功能标志只会累积到下一个主要的 Swift 语言版本，然后被清除，所以我们不会将语言分拆成不兼容的方言。
95 |
96 | ## Swift论坛
97 |
98 | 1. [SwiftUI 中的新功能](https://developer.apple.com/forums/tags/wwdc2022-10052 "What's new in SwiftUI") 围绕 `WWDC2022-10052` 内容进行讨论
99 |
100 | 2. [Swift 正则表达式](https://developer.apple.com/forums/tags/wwdc2022-110357 "Meet Swift Regex") 围绕 `WWDC2022-110357` 内容进行讨论
101 |
102 | 3. [SwiftUI 导航](https://developer.apple.com/forums/tags/wwdc2022-10054 "The SwiftUI cookbook for navigation") 围绕 `WWDC2022-10054` 内容进行讨论
103 |
104 | 4. [Swift 图表](https://developer.apple.com/forums/tags/wwdc2022-10137 "Swift Charts") 围绕 `WWDC2022-10137` 内容进行讨论
105 |
106 | 5. 使用 [cmake 构建 swift](https://forums.swift.org/t/using-cmake-to-build-swift-instead-of-build-script/59095 "Using cmake to build swift") 而不是 `build-script`。
107 |
108 | `build-script` 是 `build-script-impl` 的 python 包装器，本身是一个 `shell` 脚本，然后运行 CMake，执行可以构建项目的工作主体。 例如，如果您想执行 `utils/build-script -x`，将调用 `cmake -G Xcode`。
109 |
110 | 6. **Visual Studio Code** [增加扩展包](https://forums.swift.org/t/introducing-swift-for-visual-studio-code/54246 "VSCode extension") 支持 Swift 开发
111 |
112 | 7. [SwiftNIO _ChannelInboundHandler 与 DocC 不兼容](https://forums.swift.org/t/swiftnio-channelinboundhandler-is-docc-incompatible/58611 "SwiftNIO _ChannelInboundHandler is DocC incompatible")
113 |
114 | 在阅读 swift-biome 中的 `SwiftNIO` 文档时，遇到一个问题。文档其中引用了 3 个带下划线的属性。例如：`_ChannelInboundHandler`、`_EmittingChannelHandler` 等，但是这些属性在 swift-biome 和其他基于 `SymbolGraphGen` 的工具是不可见的，包括 DocC。
115 |
116 | 8. [Foundation 中基于 KeyPath 的对比 API](https://twitter.com/natpanferova/status/1547103127429857280 "KeyPath-based comparison API in Foundation")
117 |
118 | 在 `Foundation` 中引入的 `KeyPathComparator` API，比 Swift 中的 `sorted(by:)` 方法更清晰。这个 API 可以根据数组中的某个特定元素进行排序。
119 |
120 | 
121 |
122 |
123 | ## 推荐博文
124 |
125 | **SwiftUI 动画系列**，文章结合动画 Gif 原图和源码为案例，深入探讨了如何创建应用 SwiftUI 动画。
126 |
127 | [高级 SwiftUI 动画 — Part 1：Paths](https://mp.weixin.qq.com/s/5KinQfNtcovf_451UGwLQQ)
128 |
129 | **摘要：** 本文主要介绍了显式动画和隐式动画，以及针对 Animatable 协议的相关讨论。
130 |
131 | [高级 SwiftUI 动画 — Part 2：GeometryEffect](https://mp.weixin.qq.com/s/rE_HILLt-uxzScS7wXh5jw)
132 |
133 | **摘要：** 主要介绍使用新工具 GeometryEffect 创建 SwiftUI 动画。GeometryEffect是一个符合Animatable 和 ViewModifier 的协议。
134 |
135 | [高级 SwiftUI 动画 — Part 3：AnimatableModifier](https://mp.weixin.qq.com/s/M6MW3idXS6jZJtl4Mz5DGQ)
136 |
137 | **摘要：** 本文主要介绍使用 AnimatableModifier 完成更加复杂的动画效果。AnimatableModifier 是一个 ViewModifier，符合 Animatable 协议，如果对这个协议不了解可以阅读之前发布的两篇文章。
138 |
139 | [SwiftUI 动画进阶 — Part4：TimelineView](https://mp.weixin.qq.com/s/9OBtFNb5ddnx4_fS93Mnrg)
140 |
141 | **摘要：** 前三篇高级 SwiftUI 动画是作者在实战中总结的内容。本篇文章，我们将详细地探索 TimelineView。
142 |
143 | [SwiftUI 动画进阶 — Part 5：Canvas](https://mp.weixin.qq.com/s/0kkHpzv4Y9O5d7InEAKbEw)
144 |
145 | **摘要：** 本篇文章将探索 Canvas 视图。从技术上讲，它不是一个动画视图，但当它与第四部分的 TimelineView 结合时，可以现实很多有趣的功能。
146 |
147 | ## 关于我们
148 |
149 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
150 |
151 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
152 |
153 |
154 |
155 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
156 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_11.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第二期**，每个模块还在调整磨合期。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 平凡的八月，不平凡的世界，你若落后，必定挨打，你若前进，方得始终！**Swift社区**，给你最新的指引，给你最真的铠甲！
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：已消失 5 年 iPhone 电量百分比为何现在回归
12 | >
13 | > 提案：和脚本语言相媲美的字符串算法
14 | >
15 | > Swift 论坛：你是否希望支持在 Windows 上构建 Swift
16 | >
17 | > 推荐博文：Swift社区 成立文章仓库
18 |
19 | ## 新闻和社区
20 |
21 | ### 已消失 5 年 iPhone 电量百分比为何现在回归？
22 |
23 | 2017年，iPhone X 以后，电量百分比一直隐藏在下拉通知栏，而现在，在最新测试版的 iOS 16系统中，电量百分比以数字形式被写入电池图标内。
24 |
25 | 
26 |
27 | 如果苹果在下一代 iPhone 上增加一个常亮显示功能，那么这种电池百分比调整也会很有用，因为用户可以在不碰手机的情况下就可查看电池状态。还有传言称，iPhone14 系列将会在 Pro 机型上采用挖孔屏，顶部更大的显示面积或许也是苹果复活百分比显示的原因之一。
28 |
29 | 苹果发言人没有立即透露这个电池百分比调整是否会延续到 iOS 16 的最终版本。这次更新目前只出现在开发者版和公测版。新iOS系统将于今年秋天发布，可能是在 9 月份，届时苹果预计将发布iPhone 14。@凤凰网科技
30 |
31 | ### 线上讲座：App 内购买的新功能
32 | 诚挚邀请您参加我们于 2022 年 8 月 18 日(周四)在线举办的“线上讲座：App 内购买的新功能”。
33 |
34 | 建议参会对象：开发人员。
35 |
36 | 注册成功并收到活动确认函后方可参会。名额有限，报满即止。
37 | 设计开发加速器活动注册指南：
38 | https://essentials.applesurveys.com/WRQualtricsControlPanel_rel/File.php?F=F_a4rFfRXziNGhoAm
39 |
40 | 请持续关注 Apple 开发者官网：https://developer.apple.com/cn/accelerator/
41 | 我们会不定期地发布下期活动信息，届时可自行申请，获得批准后即可参加活动。
42 |
43 | 了解如何使您的 App 内购买体验更加完美, 并探索 StoreKit 2 和 App Store Server API 的增强功能和 App Store Server 通知的改进。了解如何利用 App Transaction API 验证 App 的购买，为 StoreKit 模型添加属性，并在交易中保留 App 的 applicationUsername。如果您是服务器端开发人员，我们将向您展示如何充分利用 App Store 服务器通知、检索用户交易历史的其他方法，以及当您的服务器出现故障时如何进行恢复。了解如何迁移到最新的 App Store Server API 并整合 App Store 服务器通知。
44 |
45 | 在线活动议程：
46 | 10:00-10:30 StoreKit 2 的新功能
47 | 10:30-11:00 App Store 服务器 API 和服务器通知新功能
48 |
49 | ### 外媒：苹果要供应商从台湾地区向中国大陆供货时严格遵守中方规定
50 |
51 | 【环球时报综合报道】在美国众议院议长佩洛西窜访台湾遭谴责之际，美国科技巨头苹果公司已要求其供应商从台湾地区向中国大陆供货时严格遵守中国海关有关规定。截至记者 5 日发稿时，苹果方面尚未就有关报道予以置评。
52 |
53 | 《日经亚洲》5 日引述消息人士的说法报道称，苹果公司告诉其供应商，中国海关要求台湾地区生产的元件进入大陆时必须标注产地为“中国台湾”或“中国台北”。苹果公司敦促供应商严肃对待此事，避免因违规导致供货受影响。报道称，苹果公司供应商目前正在为新款iPhone和今秋其他苹果新品的元件供货做准备。消息人士称，如在进口文件、表格中或包装箱上将商品生产地标注为“台湾”，中国海关可能将商品扣留检查，违规商品将被处以 4000 元人民币罚款，或被拒绝通关。
54 |
55 | ### Apple Entrepreneur Camp 已开放申请，欢迎女性、黑人和西班牙裔/拉丁裔创业者参加
56 |
57 | 
58 |
59 | Apple Entrepreneur Camp 旨在为 App 驱动型组织中的少数群体创业者及开发者提供支持，助力其研发新一代的前沿 App 并开拓全球网络，鼓励这些创业者在技术领域不断探索并取得持续发展。
60 |
61 | 三组面向女性、黑人以及西班牙裔及拉丁裔创业者的在线课程将在 2022 年 10 月开展，欢迎选择合适的一组提交申请。课程期间，Apple 工程师将为学员提供编程指导，Apple 高层也将作为导师分享见解、启发灵感。申请截止日期为 2022 年 8 月 24 日。
62 |
63 | ## 提案
64 |
65 | ### 通过的提案
66 |
67 | [SE-0365](https://github.com/apple/swift-evolution/blob/main/proposals/0365-implicit-self-weak-capture.md "SE-0365") **在 `self` 被解包后，允许为`weak self`捕获隐式`self`** 提案已通过。
68 |
69 | 从 **SE-0269** 开始，当 `self` 在捕获列表中显式写入时，允许在闭包中使用**隐式 self**。 应该将这种方式支持扩展到 `weak self` 捕获，并且只要 `self` 已解包，就允许**隐式 self** 。
70 |
71 | ```Swift
72 | class ViewController {
73 | let button: Button
74 |
75 | func setup() {
76 | button.tapHandler = { [weak self] in
77 | guard let self else { return }
78 | dismiss()
79 | }
80 | }
81 |
82 | func dismiss() { ... }
83 | }
84 | ```
85 |
86 | [SE-0362](https://github.com/apple/swift-evolution/blob/main/proposals/0362-piecemeal-future-features.md "SE-0362") **即将到来的语言改进的逐渐采用** 提案已通过。该提案已在上期周报正在审查的提案模块做了详细介绍。
87 |
88 | [SE-0357](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md "SE-0357") **基于正则表达式的字符串算法** 提案已通过。
89 |
90 | 与其他比较常用的编程语言或者脚本语言相比，Swift 标准库处理字符串算法的功能明显不足。其中一些功能可以在 `NSString` 中找到，但是这些基础的功能应该在 Swift 标准库中完善。
91 |
92 | **本提案中的建议如下：**
93 |
94 | 1. 新增加到标准库的正则表达式字符串算法，功能性和实用性要和脚本语言相媲美
95 | 2. 就子序列而言，这些算法与通用 `Collection` 相同
96 | 3. `CustomConsumingRegexComponent` 协议允许第三方库提供 `industrial-strength` 作为正则表达式的可混合组件
97 |
98 | ### 正在审查的提案
99 |
100 | [SE-0368](https://github.com/apple/swift-evolution/blob/main/proposals/0368-staticbigint.md "SE-0368") **StaticBigInt** 正在审查
101 |
102 | Swift 源代码中的整数文字可以表示任意大的值。但是符合 `ExpressibleByIntegerLiteral` 协议的标准库之外的类型，在实际使用过程中受限于使用多大的文字值来构建。
103 |
104 | 因为传递给 `init(integerLiteral:)` 的值必须是标准库支持的类型，因此很难在标准库之外编写新的整数类型。
105 |
106 | [SE-0367](https://github.com/apple/swift-evolution/blob/main/proposals/0367-conditional-attributes.md "SE-0367") **优化新属性的条件编译** 正在审查
107 |
108 | 随着时间的推移，Swift 引入了一些新的属性来优化性能，提供更多的表达能力和编译检查等功能。但是在现有的源码中增加新属性意味着旧的编译器无法进行编译。
109 |
110 | 可以使用条件编译来解决这个问题，但是实现代码冗长很不方便。例如，使用 #if 检查编译器版本确定是否可以使用 `@preconcurrency` 属性，代码如下：
111 |
112 | ```Swift
113 | #if compiler(>=5.6)
114 | @preconcurrency protocol P: Sendable {
115 | func f()
116 | func g()
117 | }
118 | #else
119 | protocol P: Sendable {
120 | func f()
121 | func g()
122 | }
123 | #endif
124 | ```
125 |
126 | 通过上面的代码可以看到，这样实现会有很多重复的代码。另外 `Swift 5.6` 编译器是第一个包含 `@preconcurrency` 属性的编译器，但是有可能这个属性在 5.6 以前就被启用，或者在 `Swift 5.6` 的开发过程中启用，通过判断版本号就会有误差。建议采用下面的代码方式来规避这些问题。代码如下：
127 |
128 | ```Swift
129 | #if hasAttribute(preconcurrency)
130 | @preconcurrency
131 | #endif
132 | protocol P: Sendable {
133 | func f()
134 | func g()
135 | }
136 | ```
137 |
138 | [SE-0366](https://github.com/apple/swift-evolution/blob/main/proposals/0366-move-function.md "SE-0366") **代码上下文新增敏感关键字 move** 正在审查
139 |
140 | 在代码中使用 `move` 关键字，可以结束 `let`、`var` 或者 `consuming` 函数参数的生命周期。并通过编译器实时做出判断强制执行此操作。示例代码如下：
141 |
142 | ```Swift
143 | useX(x) // do some stuff with local variable x
144 |
145 | // Ends lifetime of x, y's lifetime begins.
146 | let y = move x // [1]
147 |
148 | useY(y) // do some stuff with local variable y
149 | useX(x) // error, x's lifetime was ended at [1]
150 |
151 | // Ends lifetime of y, destroying the current value.
152 | move y // [2]
153 | useX(x) // error, x's lifetime was ended at [1]
154 | useY(y) // error, y's lifetime was ended at [2]
155 | ```
156 |
157 | ## Swift论坛
158 |
159 | 1) [关于支持在 Windows 上构建 Swift 的讨论](https://forums.swift.org/t/swift-as-a-cross-platform-language-and-windows-support/12547/9 "Swift as a cross-platform language and Windows support")
160 |
161 | 2) [如何从数据中读取 UInt32](https://forums.swift.org/t/how-to-read-uint32-from-a-data/59431 "How To Read UInt32 from a Data?")
162 |
163 | 3) [有什么方法可以显示依赖发生的原因](https://forums.swift.org/t/any-way-to-show-what-led-to-a-dependency/59512 "Any way to show what led to a dependency?")
164 |
165 | 是否有 `SPM` 命令来显示依赖项是如何产生的？可以显示指定 Swift 包在构建中生成的所有依赖路径。
166 |
167 | 4) [如何延迟对异步方法的响应](https://forums.swift.org/t/how-do-delay-the-response-to-an-async-method/59504 "How do delay the response to an async method?")
168 |
169 | 有一个网络请求，源码如下：
170 |
171 | ```Swift
172 | func downloadRequested(_ request: DownloadRequest) async throws -> Response {
173 | let download = try await self.download(for: request)
174 |
175 | self.transferIdMap[download.transferId] = download.itemId
176 |
177 | let size = try Int64(download.dataProvider.size())
178 |
179 | return (download.transferId, size, download.originalFilename, download.dataProvider.mimeType)
180 | }
181 | ```
182 |
183 | 对这个网络请求的速率进行限制。当有很多的请求未完成时，希望延迟此方法的执行，并将异步回调返回给方法调用者。维持 `async/await` 流程。
184 |
185 | 5) [在 Linux 上使用 swift Package 中的动态库](https://forums.swift.org/t/use-a-dynamic-library-in-a-swift-package-on-linux/59510 "Use a dynamic library in a swift package on Linux")
186 |
187 | 在 Apple 平台上，使用 swift Package 中的动态库非常容易。只需要创建一个 `.xcframework` 其中包含 `.dylib` 文件和头文件，并使用 `binaryTarget` 将其添加到 Package 中。在 Linux 上，没有这么简单的解决方案。
188 |
189 | 6) [提议成立 Swift Tooling 工作组](https://forums.swift.org/t/pitch-swift-tooling-workgroup/59515 "Swift Tooling Workgroup")
190 |
191 | 目前有许多工具类领域处于无人管理的状态。应该需要有一个小组来监督、推动和指导工作。这些领域包含：**SwiftPM、SourceKit-LSP**、**VSCode 扩展**、**LSP、Swift Format**、**API Breaking Change checker**、**Swiftly**、**Docker 镜像**、**DocC**、**SwiftMarkdown** 等等。
192 |
193 | 7) [通过 JS 调用 Swift 方法](https://developer.apple.com/forums/thread/711772 "Call Swift functions from JS")
194 |
195 | 8) [如何对 NavigationLink 中的 tag 和 selection 进行转换](https://developer.apple.com/forums/thread/711841 "NavigationLink")
196 |
197 | ```Swift
198 | List(workoutTypes) { workoutType in
199 | NavigationLink(
200 | workoutType.name,
201 | destination: SessionPagingView(),
202 | tag: workoutType,
203 | selection: $workoutManager.selectedWorkout
204 | )
205 | }
206 | ```
207 |
208 | 在 iOS 16中 `init(_:destination:tag:selection:)` 方法被弃用。Apple 建议在` NavigationStack` 或者
209 | `NavigationSplitView` 的列表中使用 `NavigationLink(_:value:)`。
210 |
211 | ## 推荐博文
212 |
213 | [Swift 社区文章仓库](https://mp.weixin.qq.com/s/U1Uw7Ze9Bsmzx0Of4hh1gw)
214 |
215 | **摘要：** 给大家推荐一下 Swift社区 的文章仓库，里面整理了公众号中的文章，并进行分类（**Swift 进阶**、**Swift 基础**、**SwiftUI 进阶**、**SwiftUI 基础**、**Tips**、**iOS**、**面试**）。方便大家查找阅读。以后会同步更新维护。
216 |
217 | [解决 Flutter 引起的 iOS 内存崩溃问题](https://mp.weixin.qq.com/s/exaRmdUnpzSvlJ2BGSODgw)
218 |
219 | **摘要：** 业界首发，很多开发者会被这个问题困扰。如果你的 Flutter 版本号小于等于 `2.5.3` 或大于等于 `3.0.5`，以下描述的问题将不会发生在你的应用中，但是我相信大部分应用都会命中此区间。
220 |
221 | [swift-5.5.1-RELEASE源码编译（Xcode）](https://mp.weixin.qq.com/s/3emjAHwr7GDExBiB2cAqWQ)
222 |
223 | **摘要：** 使用 ninja 构建 `swift-5.2.4-RELEASE` 版本，然后通过 vscode 和 `lldb` 插件来调试 swift 源码。
224 |
225 | [货拉拉 iOS 司机端线程治理总结](https://juejin.cn/post/7129391597967376415 "货拉拉 iOS 司机端线程治理总结")
226 |
227 | **摘要：** 经常会收到司机反馈手机发烫，耗电，crash等等问题。线程治理专项应运而生，目的就是降低crash，手机发烫，耗电等问题，尽量给原本并不富裕的内存，雪中送炭。
228 |
229 | [使用 Swift Package 插件生成代码](https://mp.weixin.qq.com/s/0ZHfaTiJXAXrWj5qTunhLg)
230 |
231 | **摘要：** 在 Xcode 14 的公告中说明，允许在 Xcode 项目中使用 Swift Package 插件，以及一些架构更改。例如本文的Swift Package 插件生成代码。
232 |
233 | ## 关于我们
234 |
235 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
236 |
237 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
238 |
239 |
240 |
241 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
242 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_12.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第三期**，每个模块还在调整磨合期。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 夏夜恬静月色柔，绵绵思绪埋心头，**Swift社区**常逗留，今夕明朝百事欧。欧拉欧拉👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果曝出严重安全漏洞！黑客或可完全接管设备
12 | >
13 | > 提案：改进指针系列初始化和缓冲区
14 | >
15 | > Swift 论坛：使用 Swift 5.5 / Xcode 14 构建后崩溃
16 | >
17 | > 推荐博文：iOS16 引入 SwiftUI Charts
18 |
19 | ## 新闻和社区
20 |
21 | ### 苹果曝出严重安全漏洞！黑客或可完全接管设备
22 |
23 | 当地时间 8 月 19 日（周五），苹果公司（Apple）呼吁用户立刻下载最新更新。就在两天前，该公司报告了一个重大的安全漏洞，据称可以让黑客接管苹果设备。
24 | 在周三发布的安全更新中，苹果表示该漏洞可能已被用于攻击行为。
25 |
26 | “这就是我们所说的零日漏洞，也就是在公司发现并能够做出回应之前，已经被黑客所使用过的漏洞，” 美国麦迪安网络安全公司（Mandiant）的高级威胁情报顾问杰米·科利尔（Jamie Collier）介绍道。
27 |
28 | 据介绍，受本次漏洞影响的设备涵盖了几乎所有的苹果产品。其中，手机包括 iPhone 6S 及以后的型号；平板包括第五代及以后的 iPad，所有 iPad Pro，以及 iPad Air 2；电脑则是运行 MacOS Monterey 的 Mac。此外，该漏洞还能影响到部分型号的 iPod。@看看新闻
29 |
30 | ### App 和 app 内购买项目即将实行税率和价格调整
31 |
32 | 2022 年 8 月 19 日的下周开始，加纳和土耳其 App Store 的 App 及 App 内购买项目 (自动续期订阅除外) 的价格将有所提高。加纳的价格提升将包含 **12.5%** 的新增值税和 **6%** 的附加税。
33 |
34 | 您的收益将随之进行调整，并会根据不含税的价格来进行计算。《付费 App 协议》的附录 B 已更新，表明 Apple 在加纳征收和汇付适用税款。
35 |
36 | 此外，如果您在 App Store Connect. 中选择了适当的税收类别，爱沙尼亚的电子出版物的收益已经进行了调整，以反映增值税从 **9%** 下调至 5%。
37 |
38 | 以上调整生效后，在“我的 App”中“价格与销售范围”部分会随即更新。您可以随时在 App Store Connect 中更改您的 App 和 App 内购买项目的价格 (包括自动续期订阅)。如果您有提供订阅项目，您可以选择为现有订阅者保留当前价格。
39 |
40 | 苹果发言人没有立即透露这个电池百分比调整是否会延续到 iOS 16 的最终版本。这次更新目前只出现在开发者版和公测版。新 iOS 系统将于今年秋天发布，可能是在 9 月份，届时苹果预计将发布 **iPhone 14**。@凤凰网科技
41 |
42 | ### 苹果 AppleOne 将捆绑销售电话套餐：英国运营商EE是第一家
43 |
44 | 英国运营商 EE 近日宣布，它将成为第一家将苹果 Apple One 与电话套餐捆绑在一起的运营商。EE表示，苹果 Apple One 将从 8 月 31 日起包含在其 Full Works 计划中。该计划将包括 Apple One 的个人版订阅，每月费用为 14.95 英镑（约 122.44 元人民币）。
45 |
46 | 苹果 Apple One 订阅包将最多六项苹果服务捆绑到一个订阅中，个人版单独订阅价格为每月 14.95 美元（约 101.51 元人民币），包括四项苹果服务：50GB 的 iCloud+、Apple Music、Apple TV+ 和 Apple Arcade 订阅。
47 |
48 | iPhone13 系列成美国最畅销手机机型# 2022 年 Q2 美国最畅销的 10 款智能手机机型，包括苹果、三星、联想三个品牌。其中，苹果 iPhone 13、iPhone 13 Pro Max、iPhone 13 Pro 包揽前三位。三星 Galaxy S21、Galaxy S22 / Ultra 等 5 款新机进入畅销榜前十，Galaxy S22 Ultra 5G 为 2022 年 Q2 美国最畅销的安卓机型。(来源：(来源： 极目新闻))
49 |
50 | ### 赔偿 2 亿元！苹果因搜包耽误员工下班，遭 1 万多人集体起诉
51 |
52 | 据路透社 8 月 15 日报道消息，当地时间 13 日，美国加州一名法官已经签署了苹果公司的 3050 万美元（约合人民币 2 亿元）的和解协议。该诉讼持续 9 年，诉讼称苹果公司没有为下班时检查员工行李的时间付费。
53 |
54 | 起诉源于苹果之前的一项规定，这项规定要求在下班时检查苹果员工的包和个人物品。2013 年，一群苹果公司员工因被迫接受行李检查起诉苹果公司，称公司没有为搜包的时间付费。原告称，苹果零售员工在下班后通常要等几分钟，有时甚至更长时间，才能检查完他们的行李，然后才能离开他们工作的商店。在被提起诉讼后，苹果不再对员工下班前进行搜包检查。
55 |
56 | 据纽约邮报 2015 年 6 月的报道，公布的一份法庭文件显示，至少有两名苹果零售店员工直接向首席执行官库克投诉，称该公司将检查零售员工行李作为安全预防措施的规定令人尴尬和有辱人格。
57 |
58 | 集体诉讼于 2015 年被驳回，随后他们决定上诉。州法院在 2020 年对苹果作出裁决，称期望员工不带个人物品上班是不切实际的。联邦法院随后恢复了此案，美国地方法院法官威廉·阿尔苏普去年表示，他计划对原告作出简易判决，并下令对损害赔偿进行审判。
59 |
60 | 8 月 13 日，阿尔苏普在集体诉讼中批准了和解协议。这标志着该州历史上最大的安全搜查案和解。3050 万美元的和解金将支付给包括居住在加州的 14683 名苹果员工在内的一个群体，平均每位员工获得 1328 美元赔偿金。(来源：极目新闻)
61 |
62 | ## 提案
63 |
64 | ### 通过的提案
65 |
66 | [SE-0367](https://github.com/apple/swift-evolution/blob/main/proposals/0367-conditional-attributes.md "SE-0367") **优化新属性的条件编译** 提案已通过。该提案已在上期周报正在审查的提案模块做了详细介绍。
67 |
68 | ### 正在审查的提案
69 |
70 | [SE-0371](https://github.com/apple/swift-evolution/blob/main/proposals/0371-isolated-synchronous-deinit.md "SE-0371") **Isolated synchronous deinit** 提案正在审查。
71 |
72 | 此功能允许 `deinit` 中 `actor` 和 `global-actor` 的 `isolated` 类型 (GAIT)， 访问 `non-sendable` 的 `isolated` 状态，从而解除 [SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md "SE-0327") 施加的限制。这是通过在 `__deallocating_deinit()` 中实现，为跳转到执行程序提供运行时支持。
73 |
74 |
75 | [SE-0370](https://github.com/apple/swift-evolution/blob/main/proposals/0370-pointer-family-initialization-improvements.md "SE-0370") **改进指针系列初始化和缓冲区** 提案正在审查。
76 |
77 | `UnsafeMutablePointer` 系列中的类型通常需要手动管理内存分配，包括管理其初始化状态。但是，并非该系列中的每个相关类型都具有一定的功能来管理内存的初始化状态。分配后涉及的状态如下：
78 |
79 | 1. 没有绑定和没有初始化（从 `UnsafeMutableRawPointer.allocate()` 返回）
80 | 2. 绑定到类型，没有未初始化（从 `UnsafeMutablePointer.allocate()` 返回）
81 | 3. 绑定到类型，并初始化
82 |
83 | 只要内存未初始化，就可以安全地释放内存。
84 |
85 | 我们打算完善该系列中每个相关成员的初始化功能：`UnsafeMutablePointer`、`UnsafeMutableRawPointer`、`UnsafeMutableBufferPointer`、`UnsafeMutableRawBufferPointer`、`Slice` 和 `Slice`。该功能将允许在更多种类的情况下管理初始化状态，包括更轻松地处理部分初始化的缓冲区。
86 |
87 | [SE-0365](https://github.com/apple/swift-evolution/blob/main/proposals/0365-implicit-self-weak-capture.md "SE-0365") **增加对协议 CustomDebugStringConvertible 到 AnyKeyPath 的一致性** 提案正在审查。
88 |
89 | ## Swift论坛
90 |
91 | 1) 围绕 [提议 Async buffered channel](https://forums.swift.org/t/pitch-async-buffered-channel/59854 "Async buffered channel") 进行的讨论
92 |
93 | 内容概括：创建一个总集 channel 可以在 Tasks 之间交流，主要用于一个 task 产生的 value 可以被另一个 task 使用。
94 |
95 | 2) [新问题：使用 Swift 5.5 / Xcode 14 构建后崩溃](https://forums.swift.org/t/new-crash-after-building-with-swift-5-5-xcode-14/59798 "使用 Swift 5.5 / Xcode 14 构建后崩溃")
96 |
97 | 内容概括：swift 代码使用地址引用传入 NSMutableArray 类型给 Objective-C，Objective-C会返回 Array 的地址给 Swift 代码，当 iteration loop 返回的 array 时发生崩溃。可能原因：Swift ARC 内存优化释放指针引起的崩溃。
98 |
99 | 3) [用于 SwiftSyntax 的新 Swift 解析器](https://forums.swift.org/t/a-new-swift-parser-for-swiftsyntax/59813 "用于 SwiftSyntax 的新 Swift 解析器")
100 |
101 | 内容概括：SwiftSyntax 是一个 Swift Package，它可以解析 Swift 代码成一个树状的语义，可以对树进行操控也可以将树状的语义变回 Swift 代码。目前 SwiftSyntaxParser 是一个基于 C++ 库并且 Swift compiler 非常依赖于 C++ 库。
102 | 项目目标：完全取代 Swift parser 对 C++ 库的依赖
103 |
104 | 4) 围绕 [SE-0370 pointer family initialization improvements and better buffer slice](https://forums.swift.org/t/pitch-pointer-family-initialization-improvements-better-buffer-slices/55689 "SE-0370") 展开的讨论
105 |
106 | 5) [提议：标准库的稳定排序](https://forums.swift.org/t/pitch-document-sorting-as-stable/59880 "提议：标准库的稳定排序")
107 |
108 | 稳定排序是：在比较相同元素的情况下保持输入的顺序：例子：
109 |
110 | ```Swift
111 | var roster = [
112 | Player(first: "Sam", last: "Coffey"),
113 | Player(first: "Ashley", last: "Hatch"),
114 | Player(first: "Kristie", last: "Mewis"),
115 | Player(first: "Ashley", last: "Sanchez"),
116 | Player(first: "Sophia", last: "Smith"),
117 | ]
118 |
119 | roster.sort(by: { $0.first < $1.first })
120 | // roster == [
121 | // Player(first: "Ashley", last: "Hatch"),
122 | // Player(first: "Ashley", last: "Sanchez"),
123 | // Player(first: "Kristie", last: "Mewis"),
124 | // Player(first: "Sam", last: "Coffey"),
125 | // Player(first: "Sophia", last: "Smith"),
126 | // ]
127 | ```
128 |
129 | 从例子中看出有两个一样的 first: "Ashley", 由于输入 "Hatch" 在 "Sanchez" 之前, 稳定排序之后顺序不变。
130 |
131 | 6) [访问变量时只运行一次函数的最佳方法](https://www.reddit.com/r/swift/comments/wwgblk/best_way_to_run_a_function_only_once_while/ "访问变量时只运行一次函数的最佳方法")
132 |
133 | 7) [确保 viewDidLoad 中的嵌套闭包在函数运行之前完成的最佳方法](https://www.reddit.com/r/swift/comments/wvpxmn/what_is_the_best_way_to_make_sure_a_nested/ "确保 viewDidLoad 中的嵌套闭包在函数运行之前完成的最佳方法")
134 |
135 | ## 推荐博文
136 |
137 | [在 iOS 16 中使用 SwiftUI Charts 创建折线图](https://swdevnotes.com/swift/2022/create-a-line-chart-with-swiftui-charts-in-ios-16/ "在 iOS 16 中使用 SwiftUI Charts 创建折线图")
138 |
139 | **摘要：** Apple 在 `WWWDC 2022` 上推出了 `SwiftUI Charts`，在 `SwiftUI` 视图中实现图表功能变得非常容易。如下图：
140 |
141 | 
142 |
143 | [在 iOS 16 中使用 SwiftUI Charts 自定义折线图](https://swdevnotes.com/swift/2022/customise-a-line-chart-with-swiftui-charts-in-ios-16/ "在 iOS 16 中使用 SwiftUI Charts 自定义折线图")
144 |
145 | **摘要：** iOS 16 中引入的 SwiftUI Charts，可以快速的实现各种统计图，通过图表直观的呈现数据。本文介绍了几种自定义的折线统计图。
146 |
147 | [如何在 SwiftUI 中创建条形图](https://swdevnotes.com/swift/2021/how-to-create-bar-chart-swiftui/ "如何在 SwiftUI 中创建条形图")
148 |
149 | **摘要：** 本文展示了如何创建一个垂直条形图，其中 Y 轴表示每个类型的值。如下图：
150 |
151 | 
152 |
153 | [如何在 SwiftUI 中创建水平条形图](https://swdevnotes.com/swift/2021/horizontal-bar-chart-in-swiftui/ "货拉拉 iOS 司机端线程治理总结")
154 |
155 | **摘要：** 根据 UI 设计以及交互需求，有时候统计图需要调整 X 和 Y 轴。本文主要介绍了如何创建水平的条形图，如下图：
156 |
157 | 
158 |
159 | [使用 SwiftUI 的 Eager Grids](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/%E4%BD%BF%E7%94%A8%20SwiftUI%20%E7%9A%84%20Eager%20Grids.md "使用 SwiftUI 的 Eager Grids")
160 |
161 | **摘要：** 本篇文章主要讲解如何使用 `Eager Grids` 绘制网格视图，其中讲解了十几种网格的实现方法，并详细介绍了网格的实现原理。
162 |
163 | ## 关于我们
164 |
165 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
166 |
167 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
168 |
169 |
170 |
171 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
172 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_13.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第四期**，每个模块还在调整磨合期。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 昔孔子登泰山而小天下， 今诸君阅**Swift社区**皆足矣。请君浅读，与君共勉！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：iPhone14 Pro 刘海变“灵动岛”
12 | >
13 | > 提案：大量提案审核结果已发布
14 | >
15 | > Swift 论坛：论坛内容丰富，欢迎参与讨论
16 | >
17 | > 推荐博文：增加 App 排名的 ASO 小技巧
18 |
19 | ## 新闻和社区
20 |
21 | ### iPhone14 Pro 刘海变“灵动岛”
22 |
23 | iPhone14 Pro 来了，从外观看两个亮点，第一是新配色 #iPhone14Pro 灭霸紫# 好看吗？第二是刘海变成了药丸，不是感叹号，但是带来了 #iPhone14Pro 灵动岛#，和显示动画合为一体。
24 |
25 | 本次发布会，iphone14pro 刘海依旧，但刘海减少 30% 变更为“药丸”，并引入灵动岛设计，通过刘海变换多种交互UI。视网膜 XDR2000 尼特峰值，实现息屏显示。使用新的 A16 4nm 芯片，搭载 4800 像素主摄像头，比 iPhone 13 Pro 大了 65%，新增配“灭霸紫”配色。
26 |
27 | 9月8日凌晨，苹果秋季发布会推出 iPhone14 系列产品，其中最大亮点为 iPhone14pro 系列新增正面设计“灵动岛”。正面摄像头有一个较小的切口，在不同状态下挖孔形态不同，支持第三方应用。iPhone14 系列售价：iPhone14 5999元起，iPhone14plus 6999元起，iPhone14pro 7999元起，iPhone 14pro max 8999元起。9 月 9 日开始预售，9 月 16 日正式发售。
28 |
29 | 
30 |
31 | ### 库克：苹果将捐款支持四川地震灾区救援和重建工作
32 |
33 | 9 月 7 日消息，苹果 CEO 蒂姆库克的认证微博发布消息称：“我们心系所有受地震影响的四川民众和社区。苹果将捐款支持救援和重建工作。”
34 |
35 | 
36 |
37 | 此前，小米、宁德时代、阿里巴巴、网易、字节跳动、联想、辛选集团、比亚迪、拼多多、理想汽车等都宣布向四川地震灾区进行捐赠。
38 |
39 | ### 苹果为老款 iPhone / iPad / iPod 发布 iOS 12.5.6 更新，修复严重漏洞
40 |
41 | IT之家 9 月 1 日消息，苹果今日为老款 iPhone 发布了 iOS 12.5.6（内部版本号：16H71）更新，针对无法更新到 iOS 15 的设备进行了安全更新和错误修复。
42 |
43 | 这是自 2021 年 9 月以来苹果对 iOS 12 的首次更新，当时苹果修复了一个问题，该问题使恶意制作的 PDF、Web 内容和 App 能够执行代码。最新更新解决了自上次更新以来已在 iOS 15 中修补的漏洞。
44 |
45 | IT之家了解到，苹果会针对无法更新到 iOS 12 之后的旧 iPhone、iPad 和 iPod 提供定期更新。这些更新不会提供任何重大的功能更改或 UI 改进，但会针对旧设备可能容易受到的已知攻击提供保护。
46 |
47 | 苹果安全更新网站声明如下：
48 |
49 | 一位匿名研究人员提交的 CVE-2022-32893。
50 |
51 | 更新适用于：iPhone 5s、iPhone 6、iPhone 6 Plus、iPad Air、iPad mini 2、iPad mini 3 和 iPod touch（第 6 代）
52 |
53 | 影响：恶意制作的 Web 内容可能会执行任意代码。有报告称此问题可能已被积极利用。
54 |
55 | 描述：已通过改进边界检查解决越界写入问题。(来源： IT之家)
56 |
57 | 
58 |
59 | ### 苹果 iOS 16 更新，天气 App 新功能盘点
60 |
61 | IT之家 8 月 31 日消息，苹果在 iOS 16 中对天气应用进行了一些改变，包括新的通知类型，并增加了一些信息，从湿度、温度到能见度全方位为你提供服务。
62 |
63 | 此外，新版天气 App 中的许多新功能都融入了苹果此前收购的 Dark Sky 内容。
64 |
65 | 天气应用程序的整体设计没有重大更新，但苹果提供了更多信息。长期以来，天气应用一直都有一些小模块，从而向你显示各种信息，包括 10 天内预报、每日气温、空气质量、降水、紫外线指数、日落 / 日出时间、风、湿度、感官温度、能见度和压力等等，现在你可以点击进入这些模块中的任何一个来获取更多信息，还支持快速切换。
66 |
67 | 温度部分展示了全天的温度曲线图，包括最高和最低。这应该可以解决 iOS 15 天气应用中存在的一个问题，从而不会再有用户抱怨不清楚气温何时才是每日最低点。此外，这一部分还提供了天气状况的文本概述。在 10 天的天气预报中，你可以点击任何一天查看每日温度范围的图表，还有一个选项可以查看更大的彩色温度地图。
68 |
69 | 空气质量这块展示了您所在地区当前空气状况的图表，以及当前状况和主要污染物对健康影响的附加信息。此外，你还可以看到更大的空气质量地图，预计国内同样是由“和风天气”提供信息。
70 |
71 | 新的“降水”类似于之前版本的降水信息，显示了风暴将袭击的位置地图，还可以放大显示 12 小时降雨预报，还有一个界面显示了过去 24 小时内的降水总量详情，以及在什么时间下了多少雨、雨夹雪或雪。
72 |
73 | 感官温度提供了第二个温度图表，结合温度、湿度，风等一些其他因素，你可以更好地了解周围环境温度变化。
74 |
75 | 紫外线指数显示当前的紫外线等级和白天的最高紫外线水平。同时，它还会提供一段介绍，例如建议防晒等级。
76 |
77 | “日落和日出”可以让你知道日出或日落的时间，同时它还包括每月日出和日落的平均值和总日光的读数。
78 |
79 | “风”主要是提供每天的风速摘要，以及全天的风速、风向图表。
80 |
81 | 湿度部分显示了全天湿度的图表，分为六个小时的增量。它还提供平均湿度和露点等信息。
82 |
83 | “能见度”可提供全天的能见度范围，并提供每日摘要。
84 |
85 | “压强”显示了当前的压强、全天压强，以及压强是上升还是下降的读数。
86 |
87 | “极端天气警报”和之前一样，会显示重大的暴雨、洪水、飓风、热浪、龙卷风等其他灾害警告，预计国内还是和风天气提供信息。
88 |
89 | “天气锁屏”虽然不是天气应用程序的一部分，但在 iOS 16 中有一个专门的天气锁屏。如果是晴天，你会看到太阳，如果是雨天，你会看到下雨。
90 |
91 | 还有许多不同的天气小部件，你可以添加到任何锁屏中，还有一个更大的读数与温度，当前条件，高 / 低随着个别空气质量，紫外线指数，和温度选项。
92 |
93 | “iPad 天气”，随着 iOS 16/ iPadOS 16 更新，终于有了适用于 iPad 的天气应用，相比 iPhone 版本可以更好地适应 iPad 的大显示屏。
94 |
95 | 总之，iOS 16 更新了好多新奇的功能哦，小伙伴快去试试吧。(来源： IT之家)
96 |
97 | ## 提案
98 |
99 | ### 通过的提案
100 |
101 | [SE-0370](https://github.com/apple/swift-evolution/blob/main/proposals/0370-pointer-family-initialization-improvements.md "SE-0370") **改进指针系列初始化和缓冲区** 提案已通过。该提案已在[十二期周报](https://mp.weixin.qq.com/s/IXP8PNT4aoCnyB-V2qMY_Q)正在审查的提案模块做了详细介绍。
102 |
103 | [SE-0365](https://github.com/apple/swift-evolution/blob/main/proposals/0365-implicit-self-weak-capture.md "SE-0365") **增加对协议 CustomDebugStringConvertible 到 AnyKeyPath 的一致性** 提案已通过。该提案已在[十二期周报](https://mp.weixin.qq.com/s/IXP8PNT4aoCnyB-V2qMY_Q)正在审查的提案模块做了详细介绍。
104 |
105 | [SE-0368](https://github.com/apple/swift-evolution/blob/main/proposals/0368-staticbigint.md "SE-0368") **StaticBigInt** 提案已通过。该提案已在[十一期周报](https://mp.weixin.qq.com/s/i5a-jhRRdf36KUNRoMX_8w)正在审查的提案模块做了详细介绍。
106 |
107 | ### 拒绝的提案
108 |
109 | [SE-0371](https://github.com/apple/swift-evolution/blob/main/proposals/0371-isolated-synchronous-deinit.md "SE-0371") **Isolated synchronous deinit** 被拒绝，重新修订。该提案已在[十二期周报](https://mp.weixin.qq.com/s/IXP8PNT4aoCnyB-V2qMY_Q)正在审查的提案模块做了详细介绍。
110 |
111 | [SE-0366](https://github.com/apple/swift-evolution/blob/main/proposals/0366-move-function.md "SE-0366") **代码上下文新增敏感关键字 move** 被拒绝，重新修订。该提案已在[十一期周报](https://mp.weixin.qq.com/s/i5a-jhRRdf36KUNRoMX_8w)正在审查的提案模块做了详细介绍。
112 |
113 | ### 正在审查的提案
114 |
115 | [SE-0372](https://github.com/apple/swift-evolution/blob/main/proposals/0372-document-sorting-as-stable.md "SE-0372") **更新稳定排序文档** 提案正在审查。
116 |
117 | Swift 的排序算法在 Swift 5 之前已经更改为稳定排序，但是文档一直没有更新。本提案致力于更新稳定的排序算法文档，方便开发者使用。
118 |
119 |
120 | ## Swift论坛
121 | 1) 讨论 [Automatic 类型的一致性](https://forums.swift.org/t/automatic-type-conformance/60111 "Automatic 类型的一致性")
122 |
123 | 出发点：
124 |
125 | ```Swift
126 | private func cachedImage(for path: String?) -> AnyPublisher {
127 | guard let path = path else {
128 | return Just(nil)
129 | .eraseToAnyPublisher()
130 | }
131 | if let image = imageCache.object(forKey: NSString(string: path)) {
132 | return Just(image)
133 | .eraseToAnyPublisher()
134 | }
135 | return image(for: path)
136 | .handleEvents(receiveOutput: { [weak imageCache] (image) in
137 | imageCache?.setObject(image, forKey: NSString(string: path))
138 | })
139 | .eraseToAnyPublisher()
140 | }
141 | ```
142 |
143 | ```Swift
144 | .eraseToAnyPublisher()
145 | ```
146 |
147 | 被用到了很多次
148 |
149 | 把它提出来，写一个 Just 的 extension
150 |
151 | ```Swift
152 | extension Just: TypeConvertable {
153 | var convertable: AnyPublisher {
154 | self.eraseToAnyPublisher()
155 | }
156 | }
157 | ```
158 |
159 | 于是代码变得简洁了很多
160 |
161 | ```Swift
162 | private func cachedImage(for path: String?) -> AnyPublisher {
163 | guard let path = path else {
164 | return Just(nil)
165 | }
166 | if let image = imageCache.object(forKey: NSString(string: path)) {
167 | return Just(image)
168 | }
169 | return image(for: path)
170 | .handleEvents(receiveOutput: { [weak imageCache] (image) in
171 | imageCache?.setObject(image, forKey: NSString(string: path))
172 | })
173 | }
174 | ```
175 |
176 | 把例子变得通用一些
177 |
178 | ```Swift
179 | protocol TypeConvertable {
180 | associatedtype ReturnType
181 | var convertable: ReturnType { get }
182 | }
183 | ```
184 |
185 | 当定义一个类型转变的时候，编译器应该可以决定对应的类型和相应的转变结果。
186 | 在这个例子中返回的类型是由给定类型决定的
187 |
188 | 2) 讨论 [Xcode14 RC 不能序列化 protocol 类型](https://forums.swift.org/t/xcode-14-rc-cannot-specialize-protocol-type/60171 "Xcode14 RC 不能序列化 protocol 类型")
189 |
190 | ```
191 | // ❌ Cannot specialize protocol type 'Collection'
192 | extension Collection { ... }
193 |
194 | // ❌ Cannot specialize protocol type 'Sequence'
195 | func foo(_ x: some Sequence) { ... }
196 | ```
197 |
198 | 可能原因 macOS 12 SDK 仍然使用 Swift5.6，而不是 5.7.
199 | Swift 5.7 支持：
200 |
201 | * 自定义 protocol 可以有 associated types。 参考链接：https://github.com/apple/swift-evolution/blob/main/proposals/0358-primary-associated-types-in-stdlib.md
202 | * 在 protocol 里使用 associated type 要注意传入的类型与返回类型
203 |
204 | 3) [Swift coding style guide](https://forums.swift.org/t/swift-style-guide/60177/5 "Swift coding style guide")
205 |
206 | 一个很好的 swift style 总集文档：https://google.github.io/swift/#line-wrapping
207 |
208 | 4) 讨论 [C++ Abstract Class Inheritance and C++-Interop (to Swift Protocols)](https://forums.swift.org/t/c-abstract-class-inheritance-and-c-interop-to-swift-protocols/60170 "C++ Abstract Class Inheritance and C++-Interop (to Swift Protocols)")
209 |
210 | 5) 提问 [如何处理空的网络返回值](https://forums.swift.org/t/how-to-handle-empty-response-in-responseserializer/60155/1 "如何处理空的网络返回值")
211 |
212 | 可以参考 Alamofire 的处理方法.
213 | 参考链接: https://github.com/Alamofire/Alamofire/blob/master/Source/ResponseSerialization.swift#L925
214 | 当网络请求返回是空的时候可以判定为请求失败，同时查看返回代码是不是在 200～299 之间
215 |
216 | ## 推荐博文
217 |
218 | [SwiftUI 锁屏小组件](https://swiftwithmajid.com/2022/08/30/lock-screen-widgets-in-swiftui/ "SwiftUI 锁屏小组件")
219 |
220 | **摘要：** 随着 iOS 16 的发布，赶快来适配一下 iOS 16 最为重要的更新之一，锁屏小组件吧！
221 |
222 | [Sourcery 的 Swift Package 命令行插件](https://www.polpiella.dev/sourcery-swift-package-command-plugin "Sourcery 的 Swift Package 命令行插件")
223 |
224 | **摘要：** 作为 Swift 最流程的代码生成工具，sourcery 能够快速的生成模板代码来帮助开发者节省大量的时间。
225 |
226 | [项目中第三方库并不是必须的](https://mp.weixin.qq.com/s/p_MoRthVdlfhqSyxCkDkow)
227 |
228 | **摘要：** 作者充分的论述了第三方库在提供便利的同时也带来了相当的风险。为是否选择集成第三方库提供了一套有意义的思路。
229 |
230 | [增加 App 排名的 ASO 小技巧](https://blog.nielsmouthaan.nl/aso-tips-and-tricks-to-increase-your-apps-ranking "增加 App 排名的 ASO 小技巧")
231 |
232 | **摘要：** 偶尔也可以关注一下技术之外的东西，从另一个方面提升自己的竞争力。
233 |
234 | [云音乐 iOS 端网络图片下载优化实践](https://mp.weixin.qq.com/s/R1XLp9hjHDBdYcOI6w8psw "云音乐 iOS 端网络图片下载优化实践")
235 |
236 | **摘要：** 本文介绍了网易云音乐在图片下载的优化下实践。从想法到技术方案，再从 `SDWebImage` 源码入手，到最后的再次封装实现，都很值得一看。
237 |
238 | ## 关于我们
239 |
240 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
241 |
242 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
243 |
244 |
245 |
246 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
247 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_14.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 小时候幸福很简单，长大后简单很幸福。**Swift社区**有你未领取的小幸福，等你简简单单来开启！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：iPhone灵动岛无法适配大部分应用
12 | >
13 | > 提案：Swift 5.8 实现的提案
14 | >
15 | > Swift 论坛：`conformance` 关键字
16 | >
17 | > 推荐博文：SwiftUI 新功能 Layout 协议
18 | >
19 | > **话题讨论：** 大厂养老你会选择谁
20 |
21 | ## 新闻和社区
22 |
23 | ### iPhone 灵动岛无法适配大部分应用
24 |
25 | 近日，有海外程序员小哥哥曝光了灵动岛的开发代码，并配文称原本想安装完 Xcode 14.1 Beta版（ iOS 开发程序）去了解下 iPhone 14 Pro 的灵动岛API接口情况，但没想到，苹果并未开放 API，也就是说第三方开发人员很难自行适配灵动岛这个系统级的交互功能。如果想要适配灵动岛恐怕只能向苹果官方申请开放 API 接口。这也是为什么很多 App 至今都没能适配灵动岛的情况出现。（新浪数码）
26 |
27 | 
28 |
29 | ### App 和 App 内购买项目即将实行价格和税率调整
30 |
31 | 最早于 2022 年 10 月 5 日起，下列地区 App Store 上的 App 及 App 内购买项目 (自动续期订阅除外) 价格将有所提高：智利、埃及、日本、马来西亚、巴基斯坦、波兰、韩国、瑞典、越南和所有使用欧元货币的地区。在越南，相关的价格提升反映了要求 Apple 代扣代缴适用税款的新规定，其中适用税款包括 5% 的增值税 (VAT) 和 5% 的企业所得税 (CIT)。
32 |
33 | 您的收益将随之进行调整，并会根据不含税的价格来进行计算。《付费 App 协议》的附录 B 将会更新，表明 Apple 在越南征收和汇付适用税款。
34 |
35 | 以上调整生效后，在“我的 App”中“价格与销售范围”部分会随即更新。您可以随时在 App Store Connect 中更改您的 App 和 App 内购买项目的价格 (包括自动续期订阅)。如果您有提供订阅项目，您可以选择为现有订阅者保留当前价格。
36 |
37 | ### 苹果确认iOS16存漏洞影响新机激活
38 |
39 | 据MacRumors看到的一份备忘录，苹果称，“iOS 16有一个已知的问题，可能会影响到使用开放的Wi-Fi网络的设备激活”。为了解决这个问题，苹果表示，用户应该在初始化iOS时，在提示连接到Wi-Fi网络时选择“用iTunes连接到Mac或PC”，然后返回到之前的屏幕，使用Wi-Fi再次尝试，直到激活成功。
40 |
41 | ### 使用 iOS 16.1 Beta 版和 Xcode 14.1 Beta 版，开发实时活动功能
42 |
43 | 新的 ActivityKit 框架现已在 iOS 16.1 Beta 版和 Xcode 14.1 Beta 版中推出，探索如何通过这一框架为您的 App 构建实时活动。借由实时更新，实时活动能帮助用户跟踪您的 App 内容。App 的实时活动会显示在锁定屏幕和灵动岛中 — “灵动岛”作为一项全新设计，可以让用户直观、愉悦地体验 iPhone 14 Pro 和 iPhone 14 Pro Max。
44 |
45 | 实时活动功能和 ActivityKit 将包含在今年晚些时候推出的 iOS 16.1 中。当 iOS 16.1 发布候选版本可用时，您即可将配置了实时活动功能的 App 提交至 App Store。
46 |
47 | ## 提案
48 |
49 | ### Swift 5.8 实现的提案
50 |
51 | [SE-0372](https://github.com/apple/swift-evolution/blob/main/proposals/0372-document-sorting-as-stable.md "SE-0372") **更新稳定排序文档** 该提案已在[十三期周报](https://mp.weixin.qq.com/s/aoEL9z6U9jq7X_rqecKcuw)正在审查的提案模块做了详细介绍。
52 |
53 | [SE-0369](https://github.com/apple/swift-evolution/blob/main/proposals/0369-add-customdebugdescription-conformance-to-anykeypath.md "SE-0369") **同步 CustomDebugString 协议到 AnyKeyPath**
54 |
55 | 此提案主要目的是将 `CustomDebugStringConvertible` 的协议添加到 `AnyKeyPath`。
56 |
57 | [SE-0367](https://github.com/apple/swift-evolution/blob/main/proposals/0367-conditional-attributes.md "SE-0367") **优化新属性的条件编译** 。该提案已在[十二期周报](https://mp.weixin.qq.com/s/IXP8PNT4aoCnyB-V2qMY_Q)已通过的提案模块做了详细介绍。
58 |
59 |
60 | ## Swift论坛
61 |
62 | 1) Swift 5.7 发布! 🥳 新增功能详见：[Swift Evolution](https://www.swift.org/blog/swift-5.7-released/ "Swift Evolution")
63 |
64 | 2) [Swift Platform Work Group](https://forums.swift.org/t/initiative-swift-platform-work-group/60340 "Swift Platform Work Group")
65 |
66 | Swift community 工作组将努力提高 Swift 的平台可用性
67 |
68 | 工作组内容包括：
69 |
70 | * 拓展 Swift 可用的目标平台
71 | * 拓展 Swift 可用的主机平台
72 | * 提高 Swift 现有平台上的 Toolchain
73 | * 让 Swift 编译器可以在现有的平台上工作比如 Linux 和 Windows
74 | * 努力打造更好的跨平台 Swift 生态系统
75 |
76 | 工作组不涉及的内容有：
77 |
78 | * 涉及 Apple 已经支持的平台
79 | * 涉及低资源和裸机平台
80 |
81 | 3) 提议[使用 conformance 关键字的让协议符合要求](https://forums.swift.org/t/pre-pitch-explicit-protocol-fulfilment-with-the-conformance-keyword/60246 "使用 conformance 关键字的让协议符合要求")
82 |
83 | `conformance` 关键字的意思是：**此声明由程序员定义并满足协议要求**。`conformance` 不是 protocol 必须有的关键字。 但是，当 conformance 存在时，除非声明确实符合协议要求，否则程序格式错误。
84 |
85 | 栗子🌰：
86 |
87 | ```Swift
88 | protocol Program {
89 | func run()
90 | }
91 |
92 | struct HelloWorld: Program {
93 | // OK
94 | conformance func run() { ... }
95 |
96 | // error: function crash() does not fulfill any requirement of the protocol 'Program'.
97 | conformance func crash() { ... }
98 | }
99 | ```
100 |
101 | 4) 提议[clock.sleep(for:)](https://forums.swift.org/t/pitch-clock-sleep-for/60376 "clock.sleep(for:)")
102 |
103 | 5) 框架[用于web和swift server交互的框架](https://forums.swift.org/t/html-framework-for-swift/60241 "用于web和swift server交互的框架")
104 |
105 | * [vapor/leaf 8](https://github.com/vapor/leaf)
106 | * [vapor-community/HTMLKit 9](https://github.com/vapor-community/HTMLKit)
107 | * [Plot 13](https://github.com/JohnSundell/Plot)
108 |
109 | 6) 讨论[在init方法中使用async function](https://forums.swift.org/t/call-an-async-function-in-an-initializer/60396 "在init方法中使用async function")
110 |
111 | 7）讨论[PassthroughSubject 和 CurrentValueSubject](https://forums.swift.org/t/asyncsequence-stream-version-of-passthroughsubject-or-currentvaluesubject/60395 "PassthroughSubject 和 CurrentValueSubject")
112 |
113 |
114 | ## 推荐博文
115 |
116 | [SwiftUI Layout 协议——第 1 部分](https://swiftui-lab.com/layout-protocol-part-1/ "SwiftUI Layout 协议——第 1 部分")
117 |
118 | **摘要：** 今年 SwiftUI 新增比较实用的功能当属 Layout 协议。本篇文章主要介绍 Layout 协议的基础知识和常用功能使用。
119 |
120 | [SwiftUI Layout 协议——第 2 部分](https://swiftui-lab.com/layout-protocol-part-2/ "SwiftUI Layout 协议——第 2 部分")
121 |
122 | **摘要：** 本篇文章是 SwiftUI Layout 协议的第二部分介绍，主要讲述 Layout 协议的高级布局包含自定义动画、递归布局等功能。
123 |
124 | [SwiftUI 之 HStack 和 VStack 的切换](https://mp.weixin.qq.com/s/C739cypR-npGt7F8NLtQgQ)
125 |
126 | **摘要：** 本文介绍了当涉及到水平和垂直的变体时( HStack 和 VStack )，我们需要如何在这两者之间动态的切换。
127 |
128 | [App Store 已上架项目打开瞬闪问题](https://mp.weixin.qq.com/s/QOB5alijsV5Gg8pi4lg03g)
129 |
130 | **摘要：** 用户反馈 iPhone11 iOS14.7 下载安装 App Store 已上架项目后，点击图标，App 闪一下就回到了桌面。
131 |
132 | [实现模块化应用的本地化](https://mp.weixin.qq.com/s/8fPJbPNA7kIZhnv3I8m4tg)
133 |
134 | **摘要：** 本文详细的介绍了本地化上线的过程，建议收藏，以后新开项目作为参考。
135 |
136 | ## 关于我们
137 |
138 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
139 |
140 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
141 |
142 |
143 |
144 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
145 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_15.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第六期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 果然，十一假期与新一轮疫情撞了个满怀，远方的你还好吗？**Swift社区**愿与你携手，一起尖叫一起笑，一起撑伞一起闹！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：iPhone14 车祸检测功能摆乌龙 坐过山车自动报警
12 | >
13 | > 提案：申请将 sleep(for:) 添加到 Clock
14 | >
15 | > Swift 论坛：Bug @available 在 literal 初始化中没有效果
16 | >
17 | > 推荐博文：async/await 系列代码示例详解
18 | >
19 |
20 | **话题讨论：** 面对各厂新一轮裁员，你焦虑了吗？
21 |
22 | ## 新闻和社区
23 |
24 | ### Apple Entrepreneur Camp 现已开放申请
25 |
26 | Apple Entrepreneur Camp 旨在为 App 驱动型组织中的少数群体创业者及开发者提供支持，助力其研发新一代的前沿 App 并开拓全球网络，鼓励这些创业者在技术领域不断探索并取得持续发展。
27 |
28 | 三组面向女性、黑人以及西班牙裔及拉丁裔创业者的在线课程将在 2023 年 1 月开展，欢迎选择合适的一组提交申请。课程期间，Apple 工程师将为学员提供编程指导，Apple 高层也将作为导师分享见解、启发灵感。申请截止日期为 2022 年 12 月 5 日。
29 |
30 | 
31 |
32 | ### iPhone14车祸检测功能摆乌龙 坐过山车自动报警
33 |
34 | 据美国有线电视新闻网等多家媒体报道，近日有游客在携带苹果公司的新款手机 iPhone14 乘坐过山车时，手机会错误检测到遭遇车祸并自动报警。目前在美国游乐园，已发生多起类似事件，而造成这一切的原因是 iPhone14 自带的车祸检测功能存在问题。
35 |
36 | 
37 |
38 | 苹果在９月初发布了新款手机 iPhone14，其中一项“车祸检测”新功能颇为引人关注。该功能借助加速度传感器、陀螺仪、麦克风等多种传感器来感知四种碰撞场景，包括正面、侧面、追尾和翻车。一旦检测到车祸，系统会自动弹窗询问机主是否遭遇了紧急情况，在一定时间内若未收到回应，系统将自动报警。
39 |
40 | 不过，设计人员可能没有考虑到，乘坐过山车与汽车行驶状态容易混淆。据了解，iPhone14 上市以来，在美国多家游乐园的过山车上，都发生过报警乌龙。有的游乐园无奈之下只能提醒游客，坐过山车之前关闭车祸检测功能，或把手机调成飞行模式。(看看新闻Knews)
41 |
42 | ### 苹果自研5G芯片或要等2025年
43 |
44 | 此前爆料称，苹果将为未来的 iPhone 开发自主研发的 5G 基带芯片，但据预测，高通仍将是所有 iPhone 15 和 iPhone 16 系列机型的调制解调器供应商，这表明苹果的基带芯片至少要到 2025 年才会亮相。
45 |
46 | 海通国际证券分析师 Jeff Pu 在周五的研究报告中说，他预计 2024 年发布的 iPhone 机型（暂称 iPhone 16 系列）将使用高通尚未公布的骁龙 X75 调制解调器。与骁龙 X70 一样，X75 预计将基于台积电的 4nm 工艺制造，有助于提高能效。（IT之家)
47 |
48 | ### 欧盟批准强制苹果使用USB C接口
49 |
50 | 【欧盟将统一便携智能设备充电接口】据@央视新闻 ，欧洲议会 10 月 4 日通过一项新规，要求从 2024 年底开始，所有手机、平板电脑等便携智能设备新机都使用 USB Type-C 的充电接口。
51 |
52 | 欧洲议会当天以 602 票赞成、13 票反对的投票结果通过有关统一便携智能设备充电接口的法案。所有手机、平板电脑、数码相机、耳机、便携音箱、手持视频游戏机、电子阅读器、键盘、鼠标和便携式导航系统将在两年内统一充电接口。
53 |
54 | ## 提案
55 |
56 | ### 正在审查的提案
57 |
58 | [SE-0375](https://github.com/apple/swift-evolution/blob/main/proposals/0375-opening-existential-optional.md "SE-0375") **允许非可选非空参数传递给可选类型的参数** 提案正在审查。
59 |
60 | 在 [SE-0352](https://github.com/apple/swift-evolution/blob/main/proposals/0352-implicit-open-existentials.md "SE-0352") 提案中有一个限制，可选类型的参数不允许接受非可选参数。本提案申请更改这个限制，当非可选非空参数传递给可选类型的参数时，允许调用成功。示例代码如下：
61 |
62 | ```Swift
63 | func acceptOptional(_ x: T?) { }
64 | func test(p: any P, pOpt: (any P)?) {
65 | acceptOptional(p) // SE-0352 does not open "p"; this proposal will open "p" and bind "T" to its underlying type
66 | acceptOptional(pOpt) // does not open "pOpt", because there is no "T" to bind to when "pOpt" is "nil"
67 | }
68 | ```
69 |
70 | [SE-0374](https://github.com/apple/swift-evolution/blob/main/proposals/0374-clock-sleep-for.md "SE-0374") **将 `sleep(for:)` 添加到 `Clock`** 提案正在审查。
71 |
72 | Swift 5.7 中引入的 Clock 协议提供了一种方法来暂停到未来的某个时刻，但没有提供一种方法来休眠一段时间。这与 Task 上的静态 sleep 方法不同，后者提供了一种方法来休眠到某一时刻或一段时间。
73 |
74 | [SE-0373](https://github.com/apple/swift-evolution/blob/main/proposals/0373-vars-without-limits-in-result-builders.md "SE-0373") **取消 `result builders` 中对变量的所有限制** 提案正在审查。
75 |
76 | `result builders` 转换的实现（由 [SE-0289](https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md "SE-0289") 引入）对转换函数中的局部变量声明设置了许多限制。具体来说，局部变量需要有一个初始化表达式，它们不能被计算，它们不能有观察者，它们不能有附加的属性包装器。这些限制在 SE-0289 提案中都没有明确说明，但它们实际上是当前功能的一部分。
77 |
78 | ## Swift论坛
79 |
80 | 1) 讨论[苹果是否应该创造一个简单编程语言](https://forums.swift.org/t/should-apple-create-a-simple-programming-language/60746 "苹果是否应该创造一个简单编程语言")
81 |
82 | 2) **Bug** [@available 在 literal 初始化中没有效果](https://github.com/apple/swift/issues/61564 "@available 在 literal 初始化中没有效果")
83 |
84 | ```Swift
85 | struct Foo {
86 | let bar: String
87 | }
88 |
89 | @available(*, deprecated)
90 | extension Foo: ExpressibleByStringLiteral {
91 | init(stringLiteral value: StringLiteralType) {
92 | self.bar = value
93 | }
94 | }
95 |
96 | let a: Foo = Foo(stringLiteral: "") // warning: 'init(stringLiteral:)' is deprecated
97 | let b: Foo = "" // no warning
98 | ```
99 |
100 | 3) 讨论[重新考虑基于 property wrappers 的全局 actor 推断](https://forums.swift.org/t/reconsider-inference-of-global-actor-based-on-property-wrappers/60821 "重新考虑基于 property wrappers 的全局 actor 推断")
101 | 内容概括：
102 |
103 | 4) 提问[拆分我的信息元素](https://forums.swift.org/t/splitting-information-elements/60835 "拆分我的信息元素")
104 |
105 | ```Swift
106 | // Foo.swift
107 | //
108 | class Foo {
109 | var x : Int;
110 |
111 | init ();
112 | init (v: Int);
113 |
114 | func bar () -> Int;
115 | func bar (u:Int, v:Int) -> Int;
116 | }
117 |
118 | extension Foo {
119 | init () {
120 | ...
121 | }
122 |
123 | init (v: Int) {
124 | ...
125 | }
126 | }
127 |
128 | extension Foo {
129 | func bar () -> Int {
130 | ...
131 | }
132 |
133 | func bar (u:Int, v:Int) -> Int {
134 | ...
135 | }
136 | }
137 | ```
138 |
139 | **解决**使用 `convenience` 初始化方法, `designated` 初始化方法必须写在 class 的主体中但 `convenience` 初始化方法可以在 `extension` 中使用。
140 |
141 | ```Swift
142 | class Foo {
143 | var x: Int
144 |
145 | // Note that this is a designated init because it doesn't have the
146 | // `convenience` keyword.
147 | init() {
148 | x = 0
149 | }
150 | }
151 |
152 | extension Foo {
153 | convenience init(v: Int) {
154 | self.init()
155 | x = v
156 | }
157 | }
158 |
159 | extension Foo {
160 | func bar() -> Int {
161 | return x
162 | }
163 |
164 | func bar(u:Int, v:Int) -> Int {
165 | return x + u + v
166 | }
167 | }
168 | ```
169 |
170 | 5) 讨论 [iPhone 拍照和激光雷达数据采集](https://forums.swift.org/t/iphone-picture-taking-and-lidar-data-acquisition/60799 "iPhone 拍照和激光雷达数据采集")
171 |
172 | 6) 讨论[使用 @MainActor 确保在主线程上执行](https://forums.swift.org/t/using-mainactor-to-ensure-execution-on-the-main-thread/60764 "使用 @MainActor 确保在主线程上执行")
173 |
174 | 7) 讨论 [switch 语句的替代方法](https://forums.swift.org/t/an-alternative-to-the-switch-statement/60714/10 "switch 语句的替代方法")
175 |
176 | 8) 讨论[累积 HTTP 请求 body 部分：存储 ByteBuffer 是个好主意吗？](https://forums.swift.org/t/accumulating-http-request-body-parts-is-storing-bytebuffer-s-a-good-idea/60813 "累积 HTTP 请求nody部分：存储 ByteBuffer 是个好主意吗？")
177 |
178 |
179 | ## 推荐博文
180 |
181 | [Sendable 和 @Sendable 闭包 —— 代码实例详解](https://mp.weixin.qq.com/s/IA9CgMjZf63_RFwNBB9QqQ "Sendable 和 @Sendable 闭包代码实例详解")
182 |
183 | **摘要：** Sendable 和 @Sendable 是 Swift 5.5 中的并发修改的一部分，解决了结构化的并发结构体和执行者消息之间传递的类型检查的挑战性问题。
184 |
185 | [Swift 中的 async/await —— 代码实例详解](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/19%20Swift%20中的async:await%20——代码实例详解.md "Swift 中的 async/await —— 代码实例详解")
186 |
187 | **摘要：** async-await 是在 WWDC 2021 期间的 Swift 5.5 中的结构化并发变化的一部分。Swift中的并发性意味着允许多段代码同时运行。这是一个非常简化的描述，但它应该让你知道 Swift 中的并发性对你的应用程序的性能是多么重要。有了新的 async 方法和 await 语句，我们可以定义方法来进行异步工作。
188 |
189 | [Swift AsyncSequence —— 代码实例详解](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/20%20Swift%20AsyncSequence%20——%20代码实例详解.md "Swift AsyncSequence —— 代码实例详解")
190 |
191 | **摘要：** `AsyncSequence` 是并发性框架和 [SE-298](https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md "SE-298") 提案的一部分。它的名字意味着它是一个提供异步、顺序和迭代访问其元素的类型。换句话说：它是我们在 Swift 中熟悉的常规序列的一个异步变体。
192 |
193 | [Swift AsyncThrowingStream 和 AsyncStream ——— 代码实例详解](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/21%20Swift%20AsyncThrowingStream%20和%20AsyncStream%20———%20代码实例详解.md "Swift AsyncThrowingStream 和 AsyncStream ——— 代码实例详解")
194 |
195 | **摘要：** `AsyncThrowingStream` 和 `AsyncStream`是 Swift 5.5 中由 [SE-314](https://github.com/apple/swift-evolution/blob/main/proposals/0314-async-stream.md "SE-314") 引入的并发框架的一部分。异步流允许你替换基于闭包或 Combine 发布器的现有代码。
196 |
197 | [Swift 中的 MainActor 使用和主线程调度](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/22%20Swift%20中的%20MainActor使用和主线程调度.md "Swift 中的 MainActor 使用和主线程调度")
198 |
199 | **摘要：** MainActor 是 Swift 5.5 中引入的一个新属性，它是一个全局 actor，提供一个在主线程上执行任务的执行器。在构建应用程序时，在主线程上执行UI更新任务是很重要的，在使用几个后台线程时，这有时会很有挑战性。使用 `@MainActor` 属性将帮助你确保你的UI总是在主线程上更新。
200 |
201 | ## 话题讨论
202 |
203 | **面对各厂新一轮裁员，你焦虑了吗？**
204 |
205 | 
206 |
207 | 欢迎留下你的想法
208 |
209 | ## 关于我们
210 |
211 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
212 |
213 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
214 |
215 |
216 |
217 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
218 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_16.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第七期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 当你来到双水村以外的大世界，你的人生目标便不单单是一名庄稼人了。**Swift社区**陪你一起成长，一起创造更多可能！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：【挑战上岛】适配实时活动和灵动岛
12 | >
13 | > 提案：函数反向部署
14 | >
15 | > Swift 论坛：围绕 Swift 6 lock 展开的讨论
16 | >
17 | > 推荐博文：推荐 500+ 款 App UI 设计
18 | >
19 | > 工具推荐：妙言
20 | >
21 | > **话题讨论：** 如果您年龄超过 35 岁被裁员，再入职时能接受降薪吗？
22 |
23 | ## 新闻和社区
24 |
25 | ### 挑战上岛：适配实时活动和灵动岛
26 |
27 | Apple 大中华区设计与开发加速器推出全新挑战活动，邀请开发团队限期完成实时活动和灵动岛适配。
28 |
29 | 实时活动用于在 iPhone 锁屏以及灵动岛上显示来自 App 的最新信息，帮助用户及时查看当前任务和事件的进展。参与此次活动，您将了解如何设计和开发您的实时活动，以及如何利用灵动岛带来更出色的用户体验。
30 |
31 | 我们会提供主题设计与开发讲座，您将了解如何设计和开发您的实时活动，以及如何利用灵动岛带来更出色的用户体验。
32 |
33 | 参与讲座的开发团队可在讲座当天报名参与实时活动和灵动岛适配挑战，通过审核后可获得一对一的咨询与深度辅导。参加挑战，并能够在 2022 年 12 月 20 日前完成适配和上线的团队，将有机会获得更多 App 的推广机会。
34 |
35 | 名额有限。请在 2022 年 11 月 8 日前报名参加。
36 |
37 | 要报名参加，您必须是位于大中华区的 Apple Developer Program 成员。
38 |
39 | ### 用 SwiftUI 实现 App 导航
40 |
41 | 导航是一个 App 的核心，它可以将用户带往 App 里功能不同的页面当中，因此，清晰而强大的导航架构对 App 而言是非常重要的。通过本次活动，我们将从设计和研发两方面来为您介绍，如何使用 SwiftUI 来实现 App 的导航架构，让用户能快速定位到 App 的各项功能。
42 |
43 | 名额有限。请在 2022 年 11 月 7 日前报名参加。
44 |
45 | 要报名参加，您必须是位于大中华区的 Apple Developer Program 成员。
46 |
47 | ### 使用最新 Beta 版本，做好充足准备
48 |
49 | Beta 版iOS 16.2、iPadOS 16.2、 macOS 13.1、Apple tvOS 16.2 和 watchOS 9.2 现已推出。请确认您的 App 在这些版本上工作正常，确保 App 做好准备。要利用最新 SDK 中的改进功能，请务必使用 Xcode 14.1 RC 2 进行构建和测试。
50 |
51 | 要了解之前 Beta 版本中的已知问题是否已解决或是否有临时应对办法，请查看最新的发布说明。如果您遇到问题或有其他反馈，请告诉我们。我们十分重视您的反馈，并相信您的反馈对我们解决问题、优化功能和更新文档将大有助益。
52 |
53 | ### Apple Search Ads 推出全新广告投放位置，现已亮相 App Store
54 |
55 | 
56 |
57 | Apple Search Ads 让您能轻松地在 App Store 上推广自己的 App。现在，借助全新的“Today”标签页和产品页广告投放位置，您在 App Store 上提升 App 曝光度的机会大大增加 — 当人们首次登陆、搜索特定内容和浏览要下载的 App 时，都是您推广自己 App 的大好时机。
58 |
59 | 在中国大陆的 App Store 上暂不可用。
60 |
61 | ## 提案
62 |
63 | ### 通过的提案
64 |
65 | [SE-0375](https://github.com/apple/swift-evolution/blob/main/proposals/0375-opening-existential-optional.md "SE-0375") **允许非可选非空参数传递给可选类型的参数** 提案已通过。该提案已在[十五期周报](https://mp.weixin.qq.com/s/x-ufc5MauRGfoY571WePFA)正在审查的提案模块做了详细介绍。
66 |
67 | [SE-0373](https://github.com/apple/swift-evolution/blob/main/proposals/0373-vars-without-limits-in-result-builders.md "SE-0373") **取消 `result builders` 中对变量的所有限制** 提案已通过。该提案已在[十五期周报](https://mp.weixin.qq.com/s/x-ufc5MauRGfoY571WePFA)正在审查的提案模块做了详细介绍。
68 |
69 | ### 正在审查的提案
70 |
71 | [SE-0377](https://github.com/apple/swift-evolution/blob/main/proposals/0377-parameter-ownership-modifiers.md "SE-0377") **提出了新的 `borrow` 和 `take` 参数修饰符** 正在审查。
72 |
73 | 本提案提出的 `borrow` 和 `take` 参数修饰符，允许开发人员自主选择函数，用于接收不可变参数的所有权约定。这样可以通过减少调用函数所需的 ARC 来优化性能，并为 `move-only` 类型提供了必要的先决条件，指定函数是否会消耗 `move-only` 值。
74 |
75 | [SE-0376](https://github.com/apple/swift-evolution/blob/main/proposals/0376-function-back-deployment.md "SE-0376") **函数反向部署** 提案正在审查。
76 |
77 | 弹性 Swift 资源库，例如 Apple 平台 SDK 中存在的库，作为动态库分发。这些库的作者使用 `@available` 注释来指示引入声明的操作系统版本。
78 |
79 | 函数反向部署可以避免下面的缺点：
80 |
81 | 1. 当原始库可用时，首选使用原始库的 API。
82 | 2. 当客户端二进制文件永远不会使用时，API 实现的后备副本不存在。
83 |
84 | [SE-0366](https://github.com/apple/swift-evolution/blob/main/proposals/0366-move-function.md "SE-0366") **代码上下文新增敏感关键字 move** 修订后，重新审查。该提案已在[十一期周报](https://mp.weixin.qq.com/s/i5a-jhRRdf36KUNRoMX_8w)正在审查的提案模块做了详细介绍。
85 |
86 | ## Swift论坛
87 |
88 | 1) 提议[隔离函数 Value 和 Sendable](https://forums.swift.org/t/pitch-isolated-function-values-and-sendable/61046 "隔离函数 Value 和 Sendable")
89 |
90 | 2) 提议[Swift Distributed Actors (Cluster)](https://forums.swift.org/t/pitch-swift-distributed-actors-cluster/61061 "Swift 分布式 Actors (集群)")
91 |
92 | **提议动机:** 在 Swift 5.7 中，分布式 Actor 被引入为名义类型。 与 Actors 类似，它们可以使用 `distributed actor` 关键字对来声明。 就它们自己而言，它们不能真正做任何事情， 所有分布式的行为比如 actor 的行为实际上都由给定 actor 类型相关联的 ActorSystem 处理。具体来说，一个 actor 必须声明它将与什么类型的 actor 系统一起使用，如下所示：
93 |
94 | ```Swift
95 | import Distributed
96 | import DistributedCluster
97 | distributed actor Greeter {
98 | typealias ActorSystem = ClusterSystem
99 | distributed func hello(name: String) -> String {
100 | return "Hello \(name)!"
101 | }
102 | }
103 | ```
104 | 这样的 Greeter 声明可以在集群分布式 actors 系统中使用此类。 也可以声明一个模块范围的默认分布式 actor 系统类型。有关更多信息，可以参考 [Swift Distributed Actor Runtime](https://github.com/apple/swift-evolution/blob/main/proposals/0344-distributed-actor-runtime.md "Swift Distributed Actor Runtime") 和 [Swift Distributed Actor Isolation](https://github.com/apple/swift-evolution/blob/main/proposals/0336-distributed-actor-isolation.md "Swift Distributed Actor Isolation") 这是大多数用户可能使用此功能的方式，如下所示：
105 |
106 | ```Swift
107 | typealias DefaultDistributedActorSystem = ClusterSystem
108 | ```
109 | 为了避免在每个分布式 actor 模块中重复声明 ActorSystem 类型别名。这里提出的包提供了 ClusterSystem 的实现。
110 |
111 | **解决方案:** DistributedCluster 中包括 ClusterSystem 类型，它是库的核心部分。 创建之后，它会绑定到主机/端口对并开始监听传入连接:
112 |
113 | ```Swift
114 | @main
115 | struct Main {
116 | static func main() async throws {
117 | let system = await ClusterSystem("FirstSystem") { settings in
118 | settings.endpoint.host = "127.0.0.1"
119 | settings.endpoint.port = 7337
120 | }
121 |
122 | try await system.terminated
123 | }
124 | }
125 | ```
126 |
127 | 3）提议[Package Registry Authentication](https://forums.swift.org/t/pitch-package-registry-authentication/61047 "Package Registry Authentication")
128 |
129 | 在[SE-0292](https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md)（API 规范）中提出的package registry服务可能需要对其部分或全部 API 进行身份验证，以便识别执行操作的用户并相应地授权请求。
130 |
131 | **提议动机：** Web 服务中常见的身份验证方法包括基本验证 (authentication), access token 和 OAuth。 SwiftPM 目前仅支持基本验证，这限制了它与包注册服务交互的能力。
132 | 建议的解决方案: 建议修改 swift package-registry 指令和 registry 的配置并且加入 token authentication 的支持。 这些更改还应确保将来可以灵活地添加其他验证方法。
133 |
134 | 4）提议[方便的 AsyncThrowingStream.makeStream 方法](https://forums.swift.org/t/pitch-convenience-async-throwing-stream-makestream-methods/61030 "方便的 AsyncThrowingStream.makeStream 方法")
135 |
136 | 在[SE-0314](https://github.com/apple/swift-evolution/blob/main/proposals/0314-async-stream.md)中介绍了 AsyncStream 和 AsyncThrowingStream，它们充当标准库提供的 AsyncSequence。
137 |
138 | 提议动机：在使用 Async[Throwing]Stream 一段时间后，我们发现一个常见的用法是将 continuation 和 Async[Throwing]Stream 传递到不同的地方。这需要将 Async[Throwing]Stream.Continuation excaping 并且出传递给初始化程序的闭包。Escaping continuation 使用起来不方便，因为它需要对隐式 optional value 进行格外的操作。
139 |
140 | 建议的解决方案：为了填补这个不足，建议在 AsyncStream 和 AsyncThrowingStream 上添加一个新的静态方法 makeStream ，它返回 stream 和 continuation。
141 |
142 | 5) 讨论[围绕 Swift 6 lock 展开的讨论](https://forums.swift.org/t/what-does-use-async-safe-scoped-locking-instead-even-mean/61029 "围绕 Swift 6 lock 展开的讨论")
143 |
144 | 6) 讨论[围绕 leetcode 2259 题 Remove Digit From Number to Maximize Result 展开的讨论](https://forums.swift.org/t/remove-digit-from-number-to-maximize-result/61049 "围绕 leetcode 2259 题 Remove Digit From Number to Maximize Result 展开的讨论")
145 |
146 | ## 推荐博文
147 |
148 | [7 个大型 iOS 项目的 Xcode 快捷方式](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/7个大型iOS项目的Xcode快捷方式.pdf "7 个大型 iOS 项目的 Xcode 快捷方式")
149 |
150 | **摘要：** 分享的 7 个 Xcode 快捷方式，非常的实用。希望能对你的项目开发有所帮助。
151 |
152 | [SwiftUI 锁屏小组件](https://mp.weixin.qq.com/s/jYbRAJhhdE8H8xeoBnTEaA)
153 |
154 | **摘要：** iOS 呼声最高的功能之一是可定制的锁屏。终于，在最新发布的 iOS 16 得以实现。我们可以用可浏览的小组件填充锁屏。
155 |
156 | [iOS16 中的 3 种新字体宽度样式](https://mp.weixin.qq.com/s/84TG_7yFxpsXF7cHTbVbFw)
157 |
158 | **摘要：** 在 iOS 16 中，Apple 引入了三种新的宽度样式字体到 SF 字体库。1、Compressed，2、Condensed，3、Expend。
159 |
160 | [推荐 500+ 款 App UI 设计](https://mp.weixin.qq.com/s/MsFjb49JUtZlGn6XSJghyQ)
161 |
162 | **摘要：** 500+ 款 App UI 设计，激发你的设计灵感。
163 |
164 | [Swift社区回馈读者](https://mp.weixin.qq.com/s/V1KLRAVK-DEWr7Gneatr1A)
165 |
166 | **摘要：** Swift社区回馈读者 -- 送书活动还在进行中，机会不要错过，马上参与吧。
167 |
168 | ## 工具推荐
169 |
170 | **妙言：** 一个简洁好看的开源的 Mac Markdown 编辑器，没有任何多余的功能，使用原生 Swift 开发，轻量性能高，安全纯本地使用，具备语法高亮、黑暗模式、自动格式化、单独编辑、演示模式、图床等功能。
171 |
172 | 
173 |
174 | ## 话题讨论
175 |
176 | **如果您年龄超过 35 岁被裁员，再入职时能接受降薪吗?**
177 |
178 | ## 关于我们
179 |
180 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
181 |
182 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
183 |
184 |
185 |
186 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
187 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_17.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第八期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 风起雨坠袭大地，叶落冬来又一年。**Swift社区**，和你同风雨，与你共未来！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果发布最新声明！将工人健康放在首位，iPhone 14 Pro 收获需等待更长时间。
12 | >
13 | > 提案：Swift 论坛讨论人气最高的提案
14 | >
15 | > Swift 论坛：比较两个 “any Error” 的相等性
16 | >
17 | > 推荐博文：iOS 16 统计图实战汇总
18 | >
19 | > **话题讨论：** 大家觉得互联网行业会不会持续走下坡路？
20 |
21 | ## 新闻和社区
22 |
23 | ### 11 月 14 日，参与新一周的 Ask Apple 活动
24 |
25 | 
26 |
27 | 欢迎继续参与新一周激动人心的 Ask Apple 开发者系列活动，与 Apple 专家直接交流沟通。针对如何将最新技术集成到您的 App 中、设计直观的 UI，以及测试最新软件等主题大胆提问。
28 |
29 | 活动将于 11 月 14 日至 18 日举行，届时将提供多种语言和多个时区的在线一对一咨询和小组 Q&A。现已面向 Apple Developer Program 和 Apple Developer Enterprise Program 的当前成员开放注册。
30 |
31 | Ask Apple 开发者系列活动终场周将在 12 月推出，敬请关注详情。
32 |
33 | ### 苹果发布最新声明！将工人健康放在首位，iPhone 14 Pro 收获需等待更长时间。
34 |
35 | 11 月 7 日，苹果对 iPhone 14 Pro 和 iPhone 14 Pro Max 目前的供应情况做出最新声明。苹果称，富士康郑州工厂目前的产能大幅度降低，iPhone 14 Pro 和 iPhone 14 Pro Max 的出货量将低于预期。
36 |
37 | 苹果表示，“我们继续看到对 iPhone 14 Pro 和 iPhone 14 Pro Max 机型的强劲需求。然而，我们现在预计 iPhone 14 Pro 和 iPhone 14 Pro Max 的出货量将低于我们之前的预期，顾客将需要等待更长的时间才能收到新产品。”
38 |
39 | 苹果称，正在与供应商密切合作，以恢复正常的生产水平，同时确保每个工人的健康和安全。
40 |
41 | ### macOS Ventura 更高效，更尽兴，更跨界。
42 |
43 | macOS Ventura 让各种日常操作都进化成神操作。一波新技能助你搞定更多，一众常用 app 能分享和协作，晋级的游戏让你更投入，还有种种妙招能拉上其他设备一起显身手。
44 |
45 | 优化的搜索功能，搜索功能可提供更准确、更完整的搜寻结果，还能在你键入前就提供搜索建议。
46 |
47 | 聚焦的快速操作，现在，你可使用聚焦搜索快速执行操作，比如设置闹钟、开启专注模式、用 Shazam 查找歌名、运行快捷指令等。
48 |
49 | 共享标签页组，从 Safari 浏览器直接分享标签页和书签，或发送信息。无论是与好友规划行程，还是与家人选购沙发，你都可以在一处地方集中分享所有标签页。而你的伙伴也可把他们的标签页添加进来。
50 |
51 | 收发信息的新技能，现在，你可对刚发出的信息进行编辑，或是将其撤回。另外，对于无法及时回复，想回头再来处理的信息，可标为未读。
52 |
53 | iCloud 共享照片图库，可与最多五人顺畅地分享照片和视频，鼓励大家一起制作家庭照片集，让回忆更丰富完整。iCloud 共享照片图库会把家人们的美好回忆都集于一处，让每个家庭成员随时都能欣赏，即使不是自己拍摄或编辑的照片也能看到。
54 |
55 | 多种智能的共享方式，共享照片图库可以根据开始日期或照片中的人物，选取想要囊括的内容来进行设置。完成后，你可以手动分享，也可以看看边栏里新的“为共享图库推荐”，根据它的智能建议将照片添加进来。
56 |
57 | 在 App 之间切换，轻点一下，可在各 app 和窗口之间流畅切换；点按桌面任意位置，则能快速返回某个文件或文件夹。
58 |
59 | FaceTime 通话也能玩接力了，轻轻一点，就能在设备之间转移 FaceTime 通话，方便你随时换上合适的设备。
60 |
61 | 让 iPhone 兼职网络摄像头，iPhone 强大的摄像头系统配合 Mac，能实现以往普通网络摄像头做不到的效果。只要将 iPhone 靠近 Mac，输入源就会自动切换为 iPhone，而且过程是无线的，不用动手插拔。
62 |
63 | 更多 macOS Ventura 新功能请查阅 https://www.apple.com.cn/macos/ventura/
64 |
65 | ## 提案
66 |
67 | 提案模块本期没有新的状态更新。下面推荐几个在 **Swift 论坛讨论人气最高**的往期提案。感兴趣的小伙伴可以去参与讨论。
68 |
69 | 提案 SE-0374: [将 sleep(for:) 添加到 Clock](https://forums.swift.org/t/se-0374-add-sleep-for-to-clock/60787/19 "SE-0374")。该提案已在[十五期周报](https://mp.weixin.qq.com/s/x-ufc5MauRGfoY571WePFA)正在审查的提案模块做了详细介绍。
70 |
71 | 提案 SE-0376: [函数反向部署](https://forums.swift.org/t/se-0376-function-back-deployment/61015/16 "SE-0376")。该提案已在[十六期周报](https://mp.weixin.qq.com/s/_igJkQdGWEGSfbDmVL9bbg)正在审查的提案模块做了详细介绍。
72 |
73 | 提案 SE-0377: [提出了新的 borrow 和 take 参数修饰符](https://forums.swift.org/t/se-0377-borrow-and-take-parameter-ownership-modifiers/61020/14 "SE-0377")。该提案已在[十六期周报](https://mp.weixin.qq.com/s/_igJkQdGWEGSfbDmVL9bbg)正在审查的提案模块做了详细介绍。
74 |
75 | 提案 SE-0366: [代码上下文新增敏感关键字 move 修订后](https://forums.swift.org/t/se-0366-second-review-take-operator-to-end-the-lifetime-of-a-variable-binding/61021/14 "SE-0366")。该提案已在[十一期周报](https://mp.weixin.qq.com/s/i5a-jhRRdf36KUNRoMX_8w)正在审查的提案模块做了详细介绍。
76 |
77 | ## Swift论坛
78 |
79 | 1) [Move-Only 类型的非正式介绍](https://forums.swift.org/t/an-informal-introduction-to-move-only-types/61358 "Move-Only 类型的非正式介绍")
80 |
81 | 2) [相同的值相等的复杂性保证](https://forums.swift.org/t/same-values-equality-complexity-guarantees/61334 "相同的值相等的复杂性保证")
82 |
83 | ```Swift
84 | let foo: String = ....
85 | let bar = foo
86 | foo == bar // is this O(1) ?
87 | ```
88 |
89 | 3) 资料分享 [swift package SignalHandler](https://forums.swift.org/t/signal-handling-in-swift/61351 "swift package SignalHandler")
90 |
91 | 4) 讨论[在 Linux 上使用 5.7 `Regex` 的问题](https://forums.swift.org/t/issues-with-using-5-7-regex-on-linux/61344 "在 Linux 上使用 5.7 Regex 的问题")
92 |
93 | 5) 讨论 [Swift 论坛的 iOS 应用](https://forums.swift.org/t/an-ios-app-for-the-swift-forum/61335/1 "Swift 论坛的 iOS 应用")
94 |
95 | Discourse Hub App可以用来浏览Swift论坛内容，App基于WebView，本质与用浏览器没有区别😂
96 |
97 | 6) 讨论[检测 Mac 设备上可用的 USB 端口数量](https://forums.swift.org/t/detect-the-number-of-usb-ports-available-on-the-mac-device/61321 "检测 Mac 设备上可用的 USB 端口数量")
98 |
99 | 7) 讨论[比较两个“any Error”的相等性](https://forums.swift.org/t/comparing-two-any-error-s-for-equality/61338 "比较两个“any Error”的相等性")
100 |
101 | 问题描述：有一个错误类型，它包含另一个存在的any Error：
102 |
103 | ```Swift
104 | @frozen public
105 | struct RecursiveError:Error
106 | {
107 | /// The location (key or index) where the error occurred.
108 | public
109 | let location:Location
110 | /// The underlying error that occurred.
111 | public
112 | let error:any Error
113 |
114 | @inlinable public
115 | init(_ error:any Error, in location:Location)
116 | {
117 | self.location = location
118 | self.error = error
119 | }
120 | }
121 | ```
122 |
123 | **Unit Test:**
124 |
125 | ```Swift
126 | $0.test(name: "int32-to-uint8", decoding: bson,
127 | failure: RecursiveError.init(
128 | IntegerOverflowError.int32(.max),
129 | in: "int32"))
130 | {
131 | try $0["int32"].decode(to: UInt8.self)
132 | }
133 | ```
134 |
135 | **解决方法：**
136 |
137 | ```Swift
138 | extension Error where Self:Equatable
139 | {
140 | fileprivate
141 | func equals(_ other:any Error) -> Bool
142 | {
143 | (other as? Self).map { $0 == self } ?? false
144 | }
145 | }
146 | ```
147 |
148 | 8) 讨论 [Boolean 运算和 `async let`](https://forums.swift.org/t/boolean-operators-and-async-let/61354 "Boolean 运算和 `async let`")
149 |
150 | **执行：**
151 |
152 | ```Swift
153 | async let first: Int[] = someAsyncCall()
154 | async let second: Int[] = anotherAsyncCall()
155 |
156 | let bothEmpty = (await first).isEmpty && (await second).isEmpty
157 | // or
158 | let bothEmpty = await (first.isEmpty && second.isEmpty)
159 | // or any other variation I can think of
160 | ```
161 |
162 | **会有以下 Error：**
163 |
164 | ```
165 | 'async let' in an autoclosure that does not support concurrency
166 | Capturing 'async let' variables is not supported
167 | ```
168 |
169 | Boolean 运算是使用标记为自动闭包的 rhs 参数定义的，这意味着右侧的表达式会自动捆绑到闭包中，从而延迟其执行直到需要。 值得注意的是，这个 rhs 闭包属性没有被标记为 async ，所以没有 await 语句可以出现在它的“内部”。
170 |
171 | **解决：**
172 |
173 | ```Swift
174 | let bothEmpty = await [first, second].allSatisfy(\.isEmpty)
175 | ```
176 |
177 | ## 推荐博文
178 |
179 | [在 iOS16 中用 SwiftUI 图表定制一个线图](https://github.com/SwiftCommunityRes/article-ios/blob/main/resource/16%20在iOS16中用SwiftUI图表定制一个线图.md "在 iOS16中用SwiftUI图表定制一个线图")
180 |
181 | **摘要：** 在 iOS 16 中引入的 SwiftUI 图表，可以以直观的视觉格式呈现数据，并且可以使用 SwiftUI 图表快速创建。本文演示了几种定制折线图并与区域图结合来展示数据的方法。
182 |
183 | [在 Swift 图表中使用 Foudation 库中的测量类型](https://mp.weixin.qq.com/s/k2KtSq1e6E5gMfVSu6Jmhw)
184 |
185 | **摘要：** 本篇文章使用今年推出的新的 Swift Charts 框架，实现如何绘制默认不符合 Plottable 协议的类型的数据。
186 |
187 | [在 iOS 16 中用 SwiftUI Charts 创建一个折线图](https://mp.weixin.qq.com/s/V_qXskB41WYHwaPdV877mg)
188 |
189 | **摘要：** 苹果在 WWWDC 2022 上推出了 SwiftUI 图表，本文展示了如何用比以前从头开始创建同样的折线图少得多的代码轻松创建折线图。
190 |
191 | [如何在 SwiftUI 中创建条形图](https://mp.weixin.qq.com/s/xPykVjkb9aLtu8rha3tQqA)
192 |
193 | **摘要：** 本文将展示如何创建一个垂直条形图，其中矩形的高度将代表每个类别的值。
194 |
195 | [Flutter 实战整理](https://github.com/SwiftCommunityRes/article-ios#8 "Flutter 实战")
196 |
197 | **摘要：** 文章仓库增加 Flutter 实战模块，整理相关主题文章。
198 |
199 | ## 话题讨论
200 |
201 | **都说互联网红利已经没有了，那么大家觉得互联网行业会不会持续走下坡路？**
202 |
203 | 如果没有你想要的选项，请留下您满意的答案。
204 |
205 | ## 关于我们
206 |
207 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
208 |
209 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
210 |
211 |
212 |
213 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
214 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_18.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第九期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 蝴蝶的生命之所以如此短暂，因为它的翅膀太过精致了。Swift社区之所以浩瀚汹涌，因为它总想牵动起每一位读者的心！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果 70 亿收购曼联消息不实
12 | >
13 | > 提案：Package 注册表认证
14 | >
15 | > Swift 论坛：讨论数组的悬空指针
16 | >
17 | > 推荐博文：灵动岛开发
18 | >
19 | > **话题讨论：**
20 | >
21 | > 世界杯你赚钱了吗？
22 | >
23 | > 你觉得国足几年内能进世界杯？
24 |
25 | ## 新闻和社区
26 |
27 | ### 苹果 70 亿收购曼联消息不实
28 |
29 | 此前，有消息称苹果有意以 70 亿美元收购曼联。11 月 25 日消息，有多位知情人士表示，这条消息并不属实，苹果目前不准备收购英超俱乐部曼联。
30 |
31 | 
32 |
33 | 据悉，苹果收购曼联这条消息出自英国小报《The Daily Star》，苹果公司计划斥资大约 70 亿美元用于收购曼联，但据外媒 MacRumors 直接联系多名知情人士，确认这则报道是错误的、不实的。虽然没有收购曼联的计划，但苹果一直在推动体育内容的发展。该公司与 MLB 合作，在 2022 年常规赛期间，每周在 Apple TV + 上播放“ Friday Night Baseball ”两场比赛，并且在未来10年内，它将成为 MLS 比赛的独家供应商。
34 |
35 | 虽然苹果不准备收购曼联，但确实在推进体育方面的内容。苹果与美国职业棒球大联盟（MLB）合作，2022 年每周通过 Apple TV+ 播放常规赛。该公司还将成为未来 10 年的美国职业足球大联盟（MLS）的独家提供商。另有消息称，苹果还可能从下个赛季开始购买美国职业橄榄球联盟（NFL）的流媒体转播权。
36 |
37 | 目前，世界杯正在进行中，有关足球的消息总能吸引外界，但苹果收购曼联这事确实让人摸不着头脑。
38 |
39 | ### 供应链确认 iPhone15 全系 C 口
40 |
41 | 供应链传出苹果下一代 iPhone 15 最新规格。业内人士预计，升级焦点将集中在 Pro 上，包括 3nm AP、8GB LPDDR5 DRAM 和虚拟侧键等。基本型号的配备规格则预计包括 4nm AP、开孔设计和 48MPx 主镜头。此外，iPhone 15 系列所有机型都将采用 USB Type-C 接口。（财联社）
42 |
43 | 
44 |
45 | ### iPhone15 或告别纯直边！效果图出炉：神似 iPhone 5C
46 |
47 | 据 AppleInsider 报道，据博主 ShrimpApplePro 掌握的早期信息，iPhone15 将采用全新的边框设计，后边缘角将变圆，不再是直边框，材料也将会是钛金属。还有网友提前带来了效果图，来看看！
48 |
49 | 
50 |
51 | ## 提案
52 |
53 | ### 正在审查的提案
54 |
55 | [SE-0378](https://github.com/apple/swift-evolution/blob/main/proposals/0378-package-registry-auth.md "SE-0378") **Package 注册表认证** 提案正在审查。
56 |
57 | Web 服务使用的常用身份验证方法包括基本身份验证、访问令牌和 OAuth。SwiftPM 目前只支持基本的身份验证，这限制了它与 Package 注册服务交互的能力。
58 |
59 | Package 注册表需要对其部分或全部 API 进行身份验证，以便识别执行操作的用户并相应地授权请求。
60 |
61 | ## Swift论坛
62 |
63 | 1) 讨论[是否应该用 Codable 还是用 NSCoding](https://forums.swift.org/t/should-i-stick-with-codable-or-switch-back-to-nscoding/61604 "是否应该用 Codable 还是用 NSCoding")
64 |
65 | 2) 讨论[NSKeyedArchiver, CoreData 和其他的存储方案](https://forums.swift.org/t/nskeyedarchiver-coredata-and-other-storage-solutions/61603 "NSKeyedArchiver, CoreData 和其他的存储方案")
66 |
67 | 3) 讨论[数组的悬空指针](https://forums.swift.org/t/dangling-pointer-from-array/61609 "数组的悬空指针")
68 |
69 | ```Swift
70 | do {
71 | var array = [0, 1, 2, 3, 4]
72 | let ptrToArray = UnsafeBufferPointer(start: &array, count: array.count)
73 |
74 | for number in ptrToArray {
75 | print(number)
76 | }
77 | }
78 | ```
79 |
80 | 解决
81 |
82 | ```Swift
83 | let array = [0, 1, 2, 3, 4]
84 | array.withUnsafeBufferPointer { ptrToArray in
85 | for number in ptrToArray {
86 | print(number)
87 | }
88 | }
89 | ```
90 |
91 | 4) 讨论[如何从 ReducerProtocol 中创建的alert回调中触发操作](https://forums.swift.org/t/how-to-trigger-action-from-alert-callback-created-in-reducerprotocol/61598 "如何从 ReducerProtocol 中创建的alert回调中触发操作")
92 |
93 | 5) 讨论[键路径与闭包的代码大小差异](https://forums.swift.org/t/code-size-difference-with-keypath-vs-closure/61599 "键路径与闭包的代码大小差异")
94 |
95 | 6) 讨论[将 Objective-C 代码库迁移到 Swift](https://forums.swift.org/t/migrating-an-objective-c-codebase-to-swift/61592 "将 Objective-C 代码库迁移到 Swift")
96 | Steve Barnegren 撰写的从 Objective-C 迁移到 Swift 30 的博客文章是一本不错的读物。
97 |
98 | 7) 讨论[RawRepresentable 和 LosslessStringConvertible 的区别](https://forums.swift.org/t/difference-between-rawrepresentable-string-and-losslessstringconvertible/61600 "RawRepresentable 和 LosslessStringConvertible 的区别")
99 | LosslessStringConvertible 改进了 CustomStringConvertible，这会影响其他事情，例如对 String(describing:) 的调用。
100 | 从语义上讲，LosslessStringConvertible 意味着它可以表示为字符串（例如整数），而 RawRepresentable 意味着它在底层是一个字符串（例如原始类型为 String 的枚举）。
101 |
102 | 8) 讨论[无法使用 protocol 重新创建的类 - 扩展存储属性](https://forums.swift.org/t/i-cant-recreate-my-class-using-protocols-extension-stored-properties/61589 "无法使用 protocol 重新创建的类 - 扩展存储属性")
103 | 简短的回答是“ protocol 不能定义存储的属性”。 协议一致性可以在定义类型的模块之外定义，这很自然地得出结论：这样的协议如何添加存储？
104 | 您能做的最好的事情就是让协议要求您的类型具有存储空间。 您的类型定义仍然必须实际定义该存储。
105 |
106 | 9) 讨论[状态初始化器中的 UUID](https://forums.swift.org/t/uuid-in-state-initializer/61593 "状态初始化器中的 UUID")
107 |
108 | 10) 讨论[对于金融计算用 Decimal 还是 Double](https://forums.swift.org/t/decimal-or-double-for-financial-calculations/61585 "对于金融计算用 Decimal 还是 Double")
109 |
110 | ## 推荐博文
111 |
112 | [在 SwiftUI 中开发灵动岛](https://swiftwithmajid.com/2022/09/28/mastering-dynamic-island-in-swiftui/ "Mastering Dynamic Island in SwiftUI")
113 |
114 | **摘要：** 本文将详细介绍使用 WidgetKit 框架中新的 API 实现灵动岛的开发配置和自定义功能。
115 |
116 | [灵动岛快速入门教程](https://nemecek.be/blog/171/dynamic-island-and-live-activities-quick-start-tutorial "Dynamic Island (and Live Activities): Quick start tutorial")
117 |
118 | **摘要：** Dynamic Island 是 `Live Activities` API 的一部分，Live Activities API 是 `Widgets` 系统的一部分。关于 Widgets 详细使用可以参考之前发布的 [SwiftUI 锁屏小组件](https://mp.weixin.qq.com/s/jYbRAJhhdE8H8xeoBnTEaA)
119 |
120 | [iOS16 灵动岛 ActivityKit 开发](https://zhuanlan.zhihu.com/p/577728766 "iOS16 灵动岛 ActivityKit 开发")
121 |
122 | **摘要：** iOS16.1 苹果向我们开放了 ActivityKit。 使用此框架我们可以在锁定屏幕或者灵动岛上显示实时活动。
123 |
124 | ## 话题讨论
125 |
126 | **世界杯你赚钱了吗？**
127 |
128 |
129 | 14 亿人为什么选不出一支十多人的优秀团队？到底是哪里出了问题？元芳，你怎么看？国足⚽️的未来在哪里？
130 |
131 | **你觉得国足几年内能进世界杯？**
132 |
133 |
134 | 欢迎在文末留言参与讨论。
135 |
136 |
137 | ## 关于我们
138 |
139 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
140 |
141 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
142 |
143 |
144 |
145 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
146 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_19.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 十期磨一剑，废铁亦有形，**Swift社区**就是你梦想已久的香格里拉，哪怕青冥长天，纵然绿水波澜！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果汽车计划 2026 年推出，大降级！苹果汽车售价或低于 10 万美元，不支持完全自动驾驶
12 | >
13 | > 提案：Swift 选择加入 `Reflection` 元数据
14 | >
15 | > Swift 论坛：使用较新的 macOS 版本生成 `Package.swift` 文件
16 | >
17 | > 推荐博文：用 ChatGPT 写 SwiftUI
18 | >
19 | > **话题讨论：**
20 | >
21 | > 你如何看待各地疫情管控放开
22 |
23 | ## 新闻和社区
24 |
25 | ### 12 月 12 日，参与新一周的 Ask Apple 活动
26 |
27 | 
28 |
29 | 欢迎继续参与新一周激动人心的 Ask Apple，与 Apple 专家直接交流沟通，获取关于最新技术和设计问题的解答；或者只是随意听听，从对话中学习。针对如何使用最新的框架、改善 App 的 UI 设计、使用 Beta 版 OS 软件和工具进行开发等主题大胆提问。
30 |
31 | 活动将于 12 月 12 日至 16 日举行，届时将提供多种语言和多个时区的在线一对一咨询和小组 Q&A。现已面向 Apple Developer Program 和 Apple Developer Enterprise Program 的当前成员开放注册。
32 |
33 | ### 苹果汽车计划 2026 年推出，大降级！苹果汽车售价或低于 10 万美元，不支持完全自动驾驶
34 |
35 | 12 月 6 日，苹果宣布推出 Apple Music Sing 功能，该功能可以让用户通过可调节的人声和实时歌词演唱自己喜欢的歌曲。此外据彭博社报道，苹果已经缩减了其汽车项目，计划在 2026 年之前推出定价在 10 万美元以下的汽车。苹果不再计划发布完全自动驾驶的汽车，其原来想制造一辆没有方向盘和油门的自动驾驶汽车，现在已经放弃。
36 |
37 | ### Apple 宣布 App Store 定价机制最重大升级，新增 700 个价格点
38 |
39 | Apple 今日宣布对 App Store 进行问世至今最全面的定价机制升级，为开发者提供新增的 700 个价格点和全新定价工具，让开发者更轻松地针对不同国家和地区的 App Store 设定价格、管理外币汇率变化等。
40 |
41 | 
42 |
43 | ### 假日将至，请为您的 App 做好准备
44 |
45 | App Store 最繁忙的季节即将到来！确保及时更新您的 App 和产品页面，并在岁末假日到来之前做好准备。很高兴今年的整个假日季期间同样会开放 App 提交，我们非常期待看到您提交的 App。平均而言，90% 的提交内容会在 24 小时内得到审核。但请注意，在 12 月 23 日至 27 日，完成审核所需的时间可能略长一些。外国的圣诞节就相当于中国的春节，所以 12 月 23 日至 27 日就相当于中国的春节放假哟。
46 |
47 | ## 提案
48 |
49 | ### 正在审查的提案
50 |
51 | [SE-0379](https://github.com/apple/swift-evolution/blob/main/proposals/0379-opt-in-reflection-metadata.md "SE-0379") **Swift 选择加入 Reflection 元数据** 提案正在审查。
52 |
53 | 该提案旨在通过改进现有机制，并提供机会在使用 Swift Reflection 元数据的 API 中表达对反射元数据的要求，从而提高 Swift Reflection 元数据的安全性、效率和保密性。
54 |
55 | **Swift-evolution 线程**：[该提案的讨论主题](https://forums.swift.org/t/pitch-3-opt-in-reflection-metadata/58852 "该提案的讨论主题")。感兴趣的小伙伴可以参与讨论交流。
56 |
57 | [SE-0380](https://github.com/apple/swift-evolution/blob/main/proposals/0380-if-switch-expressions.md "SE-0380") **if 和 switch 表达式** 提案正在审查。
58 |
59 | 本提案介绍了使用 `if` 和 `switch` 语句作为表达式的功能，主要内容包含：
60 |
61 | * 函数、属性和闭包的返回值
62 | * 为变量赋值
63 | * 声明变量
64 |
65 | ## Swift论坛
66 |
67 | 1)讨论 [Comparable 下 == 的危险默认实现](https://forums.swift.org/t/dangerous-default-implementation-of-under-comparable/61928 "Comparable 下 == 的危险默认实现")
68 |
69 | 2)提议[Mach Port API](https://forums.swift.org/t/mach-port-api/61930 "Mach Port API")
70 |
71 | **简介:** Mach Port API 是一种难以安全使用的神秘技术。
72 | 但是，作为我们操作系统的一个组成部分，它们有时需要处理。
73 |
74 | 该提案广泛使用了mach port术语。
75 | 如果您想复习基础知识，[请查看端口、端口权限、端口集和端口命名空间](https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html#//apple_ref/doc/uid/TP30000905-CH209-TPXREF104)。
76 |
77 | **动机:** Mach ports 很难正确设置，主要是由于管理 mach port 权限的方式。 程序员需要在头脑中跟踪类型、生命周期和其他状态。
78 |
79 | Swift 的高级类型系统，最近增加了 [move-only types](https://github.com/apple/swift-evolution/blob/main/proposals/0366-move-function.md)，提供了一个新的机会来创建一个能够在编译时防止整个类错误的 Mach port 接口。
80 |
81 | **建议的解决方案:**
82 | 建立不同的类型来表示接收、发送和发送一次的权利。
83 | 提供 Mach port权限的自动生命周期管理，这与普通的 OOP 对象不同。
84 |
85 | 3)议案 [Noncopyable (或者 “move-only”) 结构和枚举](https://forums.swift.org/t/pitch-noncopyable-or-move-only-structs-and-enums/61903 "Noncopyable (或者 “move-only”) 结构和枚举")
86 |
87 | 4)议案 [@globalConstructor](https://forums.swift.org/t/pitch-globalconstructor/61901 "@globalConstructor")
88 |
89 | **简介:** `@globalConstructor` 属性提供了一种在启动可执行文件或加载动态库时自动调用函数的方法。
90 |
91 | **动机:** 在许多用例中，您可能想要执行代码而不必直接调用它。
92 |
93 | **例如：**
94 | 在您希望将库插入应用程序的位置进行调试，而无需手动调用库重建应用程序
95 | 包含可选库的插件系统将自己注册到主应用程序以更改行为
96 | 希望在启动时进行 1 次设置而不要求开发人员显式调用其配置的第三方库作者
97 | 如今，在这些情况下，开发人员不得不回退到 Objective-C/C++/C（使用 __attribute__((constructor)))，即使他们只需要调用一个 Swift 函数。
98 |
99 | **建议的解决方案:**
100 |
101 | 添加一个新的 `@globalConstructor` 属性，该属性可以添加到顶级函数，以便在启动可执行文件或加载包含该函数的动态库时自动调用它们。
102 |
103 | 5)讨论[SE-0380：if 和 switch 表达式](https://forums.swift.org/t/se-0380-if-and-switch-expressions/61899 "SE-0380：if 和 switch 表达式")
104 |
105 | 6)议案[使用较新的 macOS 版本生成 Package.swift 文件](https://forums.swift.org/t/pitch-generate-package-swift-files-with-newer-macos-versions/61925 "使用较新的 macOS 版本生成 Package.swift 文件")
106 |
107 | **简介:** 目前，没有明确定义支持的最低平台版本的 Swift Package Manager 包会自动默认为第一个支持的版本，对于许多平台来说，这是 2017 年的版本。这在某些情况下会增加新生成的包的摩擦。
108 |
109 | **动机:** 当前，在 macOS 上构建全新的 Swift Package Manager 包时，构建目标是 2017 年的 macOS 10.13。当他们添加诸如 swift-syntax 之类的具有更高最低支持版本的依赖项时，这可能是一种令人沮丧的新用户体验，导致他们必须立即弄清楚如何配置此选项。
110 |
111 | **建议的解决方案:**
112 |
113 | 我建议我们自动将 macOS 上生成的新包的最低支持版本添加到用户当前的 macOS 版本中。 例如，不是生成这个 Package.swift 内容：
114 |
115 | ```Swift
116 | let package = Package(
117 | name: "name",
118 | ...
119 | )
120 | ```
121 |
122 | 目前在 macOS 上我们将生成以下内容：
123 |
124 | ```Swift
125 | let package = Package(
126 | name: "name",
127 | platforms: [.macOS("13.0")],
128 | ...
129 | )
130 | ```
131 |
132 | 7)讨论 [“withUnsafeBytes”已弃用](https://forums.swift.org/t/withunsafebytes-is-deprecated/61891 "“withUnsafeBytes”已弃用")
133 |
134 | 8)讨论 [Linux 上标准库的自动编译是否损坏？](https://forums.swift.org/t/is-auto-compilation-of-the-standard-library-on-linux-broken/61918 "Linux 上标准库的自动编译是否损坏")
135 |
136 | 9)讨论 [Read/modify, yield, 和 non-escaping closures](https://forums.swift.org/t/read-modify-yield-and-non-escaping-closures/61902 "Read/modify, yield, 和 non-escaping closures")
137 |
138 | 10)议案 [Swift 中的 Objective-C 实现](https://forums.swift.org/t/pitch-objective-c-implementations-in-swift/61907 "Swift 中的 Objective-C 实现")
139 | 我们提出了 `@objc` 类的替代方案，其中 `Objective-C` 标头 `@interface` 声明由 Swift 扩展实现。 生成的类将在 Swift 中实现，但与 Objective-C 类没有区别，完全支持 ObjC 子类化和运行时技巧。
140 | 使用 `@objcImplementation`，您可以像编写 Objective-C 类一样手写头文件，但不是在 Objective-C 中实现方法和属性，而是在 Swift 中实现它们。
141 |
142 | ## 推荐博文
143 |
144 | [ChatGPT 注册攻略](https://zhuanlan.zhihu.com/p/589572374 "ChatGPT 注册攻略")
145 |
146 | **摘要：** Chat GPT 由人工智能公司 Open AI 于近日推出，其对自己的定义是（优化对话的语言模型）非常火爆，近期不断有研究者发布与 Chat GPT 对话的内容，但其不支持中国大陆用户的注册，把一众想尝试进去玩一玩的人拒之门外。这里为大家提供一种注册方式。核心内容在使用国外手机号获取验证码。
147 |
148 | [使用 OpenAI 的 ChatGPT 写 SwiftUI 代码](https://www.createwithswift.com/prototyping-swiftui-interfaces-with-openais-chatgpt/ "Prototyping SwiftUI interfaces with OpenAI's ChatGPT")
149 |
150 | **摘要：** 上面介绍了如何注册 ChatGPT，本篇文章介绍如何使用 ChatGPT 写 SwiftUI 代码。你觉得 ChatGPT 以后能代替基础人工吗？
151 |
152 | [SwiftUI 布局协议 - Part 1](https://mp.weixin.qq.com/s/SfqdGs8TbEjxISgrsy_yIg)
153 |
154 | **摘要：** 今年 SwiftUI 新增最好的功能之一必须是布局协议。它不但让我们参与到布局过程中，而且也给了我们一个很好的机会去更好的理解布局在 SwiftUI 中的作用。
155 |
156 | ## 话题讨论
157 |
158 | **你如何看待各地疫情管控放开**
159 |
160 | 123
161 |
162 | 欢迎在文末留言参与讨论。
163 |
164 | ## 关于我们
165 |
166 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
167 |
168 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
169 |
170 |
171 |
172 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
173 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_20.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第十一期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 |
8 | > **周报精选**
9 | >
10 | > 新闻和社区：部分 iPhone 14 Pro / Max 被爆开机闪现水平线
11 | >
12 | > 提案：`DiscardingTaskGroups` 提案正在审查
13 | >
14 | > Swift 论坛：讨论修改 SE-0368 以删除前缀 `+` 运算符
15 | >
16 | > 推荐博文：SwiftUI 的优势、劣势和缺陷
17 | >
18 | > **话题讨论：**
19 | >
20 | > 疫情放开，你处于什么阶段
21 |
22 | ## 新闻和社区
23 |
24 | ### 部分 iPhone 14 Pro / Max 被爆开机闪现水平线
25 |
26 | 一些 iPhone 14 Pro 和 iPhone 14 Pro Max 用户报告说，当设备被打开时，iPhone 显示屏上闪烁着水平线，但没有明确的原因或如何修复它。
27 |
28 | 在 Reddit 的主题帖子中，数十名 iPhone 14 Pro 用户报告说，当设备被打开时，一条或多条绿色和黄色的线条可能会在屏幕上闪烁，几秒钟后消失。根据这些用户的说法，苹果支持部门已经通知他们，该问题不是硬件缺陷造成的，而是 iOS 16 的错误 Bug。
29 |
30 | 
31 |
32 | ### iOS 16.2 不能升级 Home 应用架构
33 |
34 | 苹果已取消 iOS 16.2 升级到新 Home 家庭架构的选项，iOS 16.2 和 macOS Ventura 13.1 的主要新功能之一是能够升级到新的 Home 家庭应用架构。虽然苹果没有分享具体的变化细节，但表示，该升级为 HomeKit 配件提供了“更好的性能和可靠性”。
35 |
36 | 
37 |
38 | ### AppleWatch 或可无创测血压
39 |
40 | Apple Watch 无创测血压功能即将到来，苹果正积极积累相关技术。IT 之家 12 月 23 日消息，知情人士在今年 4 月透露，苹果计划在 Apple Watch 中添加血压监测功能，但由于遇到障碍，该项技术预计最早要到 2024 年才能推出。苹果目前也在积极地积累技术支持，美国商标和专利局（USPTO）公示了一项新的苹果专利（专利号 US 20220400959），涉及获取和分析无创血压测量数据的系统和方法。
41 |
42 | 
43 |
44 | ### iPhone15 系列将继续采用高通5G基带芯片
45 | 苹果 iPhone 15 系列将采用高通骁龙 X70 5G 基带芯，根据 DigiTimes 报道，苹果 iPhone 15 系列将继续采用高通 5G 调制解调器（基带芯片），因为苹果公司仍在继续开发自有的 5G 定制芯片。
46 |
47 | ## 提案
48 |
49 | ### 正在审查的提案
50 |
51 | [SE-0381](https://github.com/apple/swift-evolution/blob/main/proposals/0381-task-group-discard-results.md "SE-0381") **DiscardingTaskGroups** 提案正在审查。
52 |
53 | 该提案建议为 `TaskGroup` 和 `ThrowingTaskGroup` 引入一个新的布尔参数 `discardResults`。此参数将控制 `TaskGroup` 是保留其已完成子任务的结果，然后确定是传递给 `next()`，还是立即丢弃。
54 |
55 | [SE-0382](https://github.com/apple/swift-evolution/blob/main/proposals/0382-expression-macros.md "SE-0382") **Expression Macros** 提案正在审查。
56 |
57 | `Expression Macros` 提供了一种用新型表达式扩展 Swift 的方法，这些表达式可以对其参数执行任意语法转换以生成新代码。 `Expression Macros` 使得用以前只有引入新的语言特性才能实现的方式扩展 Swift 成为可能，帮助开发人员构建更具表现力的库并消除无关的样板。
58 |
59 | ## Swift论坛
60 |
61 | 1) Swift to C++ [将 Swift 参数标签合并到生成的 C++ 函数名中](https://forums.swift.org/t/swift-to-c-incorporating-swift-argument-labels-into-generated-c-function-name/62195 "将 Swift 参数标签合并到生成的 C++ 函数名中")
62 |
63 | 2) 讨论[如何测试发送动作的长时间运行效果？](https://forums.swift.org/t/how-to-test-long-running-effect-that-sends-actions/62201 "如何测试发送动作的长时间运行效果？")
64 |
65 | 3) 议案 [[Pitch] 结果构建器范围内的不合格查找](https://forums.swift.org/t/pitch-result-builder-scoped-unqualified-lookup/62190 "[Pitch] 结果构建器范围内的不合格查找")
66 |
67 | **介绍:**
68 |
69 | 结果构建器为定义声明式 DSL 提供了基础——特定领域的语言提供了在特定领域工作的定制语法，例如生成图表或文本处理。 利用结果构建器的复杂 DSL API 遇到了设计可扩展性和类型检查性能方面的问题，引入了需要解决的关键挑战。
70 |
71 | 扩展结果构建器以支持在其主体内进行范围内的非限定名称查找，即特定于构建器类型的范围内名称间距，将启用新的 API 模式，显着降低类型检查的复杂性，同时改善调用站点的美感。
72 |
73 | 4) 议案[修改 SE-0368 以删除前缀 + 运算符](https://forums.swift.org/t/pitch-amend-se-0368-to-remove-prefix-operator/62173 "修改 SE-0368 以删除前缀 + 运算符")
74 |
75 | 内容:[SE-0368](https://forums.swift.org/t/se-0368-staticbigint/59421 "SE-0368")包括对 `StaticBigInt` 的以下操作：
76 |
77 | ```Swift
78 | /// Returns the given value unchanged.
79 | public static prefix func + (_ rhs: Self) -> Self
80 | ```
81 |
82 | 这被包括在内，以便前缀 + 可以作为文字前缀包含在上下文中，在这些上下文中，值需要是 `StaticBigInt` 类型，而不是另一种类型的文字，以便与 - 对称：
83 |
84 | ```Swift
85 | let signs: [StaticBigInt] = [-1, 0, +1]
86 | ```
87 |
88 | 事实证明，这是一个源代码的突破性变化，因为有如下示例：
89 |
90 | ```Swift
91 | let a: Int = 7
92 | let b = +1 // Inferred as `StaticBigInt` because concrete `+` beats
93 | // the generic one on `AdditiveArithmetic`
94 | let c = a + b // Error: Cannot convert `b` from `StaticBigInt` to `Int`
95 | ```
96 |
97 | 之前，`b` 被赋予了 `Int` 类型，这个例子编译正确。建议修改 `SE-0368` 以删除此运算符。 这对于想要使用 `StaticBigInt` 值的代码来说是一个小小的不便，但是不存在这样的代码，因为 5.7 中不存在该类型。
98 |
99 | 这样的代码可以省略前导 + 作为解决方法。
100 |
101 | 一旦解决了源中断问题，我们就可以调查其他选项以在空闲时恢复所需的语法。
102 |
103 | 5) 讨论 [ArgumentParser 包出现 no such file 错误](https://forums.swift.org/t/no-such-file-errors-with-argumentparser-package/62183 "ArgumentParser 包出现 no such file 错误")
104 |
105 | 6) 讨论[如何打印 HTTPS URL 参数和正文](https://forums.swift.org/t/how-can-i-print-https-url-params-and-body/62153 "如何打印 HTTPS URL 参数和正文")
106 |
107 | 7) 提议 [ Guard Evaluation 会更好](https://forums.swift.org/t/pitch-better-result-success-failure-guard-evaluation/62158 " Guard Evaluation 会更好")
108 |
109 | 内容:
110 |
111 | 在 `SE-0235` 中将结果类型引入标准语言是我在构建库时最喜欢的功能之一。 当返回的 Result 用户想要评估时，通常看起来有点像这样：
112 |
113 | ```Swift
114 | let result: Result = getResult()
115 |
116 | switch result {
117 | case .success(let data):
118 | // Do something with the data here
119 | case .failure(let error):
120 | // Handle error
121 | }
122 | ```
123 |
124 | 这对大多数情况都很好。 然而，如果我们需要级联多个结果，它会变得有点难看。
125 |
126 | **例如：**
127 |
128 | ```Swift
129 | let firstResult: Result = getFirstResult()
130 |
131 | switch firstResult {
132 | case .success(let data):
133 | let secondResult: Result = getSecondResult(using: data)
134 | switch secondResult {
135 | case .success(let secondData):
136 | // Do something with secondData
137 | case .failure(let secondError):
138 | // Handle secondError
139 | }
140 | case .failure(let firstError):
141 | // Handle firstError
142 | }
143 | ```
144 |
145 | 如上所述，嵌套切换变得有点沉重。 这常常让我想起嵌套的 if 语句，作为一个“从不嵌套”的人，我通常会在这里求助于 `guard ` 关键字。 我认为 guard 关键字对于评估 Result 类型也非常有用，但是因为它现在有效，但 gaurd 关键字对于 Result type 用起来有问题。
146 |
147 | ```Swift
148 | let firstResult: Result = getFirstResult()
149 | guard case .success(let data) = firstResult else {
150 | // Handle first error - But no reference to firstError!
151 | return
152 | }
153 |
154 | let secondResult: Result = getSecondResult(using: data)
155 | guard case .success(let secondData) = secondResult else {
156 | // Handle second error - But no reference to secondError!
157 | return
158 | }
159 | ```
160 |
161 | 正如评论所暗示的那样，我没有引用 `guard` 语句的 `else` 部分中的错误类型。 据我所知，没有办法使用这种语法并访问返回的错误类型。
162 |
163 | 也许有一些方法可以通过扩展 `guard` 语句或更新 `Result` 类型来实现此功能？
164 |
165 | 所以这就是为什么我要提出这个建议。我不是确定能百分百修复。甚至不确定这是对语言的有用更改还是其他 Swift 用户想要的东西。让我们在这里讨论一下！
166 |
167 | 8) 讨论 [Swift 是否允许重载属性](https://forums.swift.org/t/are-we-allowed-to-overload-a-property-or-not/62167 "Swift 是否允许重载属性")
168 |
169 | ## 推荐博文
170 |
171 | [2021 年的 SwiftUI: 优势、劣势和缺陷](https://juejin.cn/post/7140825514108780580 "2021 年的 SwiftUI: 优势、劣势和缺陷")
172 |
173 | **摘要：** 这篇文章主要目的是帮助你理解 SwiftUI 的利弊，这样你可以就 SwiftUI 是否适合下一个项目做出更明智的决定。
174 |
175 | [用 SwiftUI 实现 AI 聊天对话 app - iChatGPT](https://juejin.cn/post/7175051294808211512 "用 SwiftUI 实现 AI 聊天对话 app - iChatGPT")
176 |
177 | **摘要：** 关于 ChatGPT 的话题，大家都不陌生，我们直入话题，因为 ChatGPT 目前限制中国访问服务，所以如果直接使用 ChatGPT 网页进行对话，还是不太方便。通过 ChatGPT SessionToken 就可以不限制网络访问，所以大家发挥想象力实现各种的聊天机器人、小程序，而原生 app 可能体验更好
178 |
179 | [SwiftUI 布局协议 - Part 2](https://mp.weixin.qq.com/s/fgHkd_EFPkNwG3G3KPq92w)
180 |
181 | **摘要：** 在 Part 1 我们探索了布局协议的基础知识，为理解布局是如何工作的打下了坚实的基础。现在，是时候深入研究那些更少提及的功能了，以及如何使用它们来为我们带来便利。
182 |
183 | ## 话题讨论
184 |
185 | **疫情放开，你处于什么阶段**
186 |
187 | 123
188 |
189 | 欢迎在文末留言参与讨论。
190 |
191 | ## 关于我们
192 |
193 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
194 |
195 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的各种交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
196 |
197 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
198 |
199 | 周报仓库：https://github.com/SwiftCommunityRes 文章中外引链接较多，可以点击 **阅读原文** 更加方便阅读。
200 |
201 |
202 | ## 关于我们
203 |
204 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
205 |
206 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
207 |
208 |
209 |
210 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
211 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_21.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第十二期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 烟花，如此短暂，却如此的奔放热烈。**Swift社区**，积聚无数力量，却只为给你展现一刹那辉煌！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果市值两年来首次跌破2万亿美元
12 | >
13 | > 提案：弃用 `@UIApplicationMain` 和 `@NSApplicationMain`
14 | >
15 | > Swift 论坛：改变一个属性包装器
16 | >
17 | > 推荐博文：iOS 应用卡顿监控与治理
18 | >
19 | > **话题讨论：**
20 | >
21 | > 您觉得烟花应该被禁止吗？
22 |
23 | ## 新闻和社区
24 |
25 | ### 苹果市值两年来首次跌破2万亿美元
26 |
27 | 鞭牛士 1 月 4 日消息，据报道，当地时间 1 月 3 日，苹果（AAPL）收报 125.07 美元，跌幅 3.74% ，市值 1.99 万亿美元。市值一夜蒸发 773 亿美元（约 5345 亿元人民币）。
28 |
29 | 
30 |
31 | Tech 星球 1 月 4 日消息，据凤凰网科技，在遭遇了去年的大幅下跌后，苹果公司市值本周二继续大幅缩水，自 2021 年 3 月以来首次跌破 2 万亿美元，面临被微软公司超越的风险。而就在一年前，苹果曾成为首家市值触及 3 万亿美元的公司。
32 |
33 | 截至周二收盘，苹果股价下跌 3.7% ，至 125.07 美元。此前，法国巴黎银行分析师杰罗姆·拉梅尔(Jerome Ramel)将苹果股票评级从“跑赢大盘”下调至“中性”，并将其目标价从 180 美元下调至 140 美元。拉梅尔还将 iPhone 2023 财年的出货量预期从 2.45 亿部下调至 2.24 亿部，以反映代工商富士康的供应链问题以及消费者削减在高端手机上的支出。
34 |
35 | 与此同时，投资者还担心，全球经济放缓和高通胀可能会损害消费者对苹果设备的需求。日本媒体报道称，苹果已经要求供应商减少为其耳机、手表和笔记本电脑生产零部件。
36 |
37 | 在经历了周二的下跌后，苹果目前的市值为 1.99 万亿美元，稍稍领先微软，后者的市值约为 1.8 万亿美元。苹果、微软、亚马逊、谷歌母公司 Alphabet 、脸书母公司 Meta 目前在标普 500 指数中的市值占比约为 18% ， 低于 2020 年一度达到的 24% 。
38 |
39 | ### TrendForce 集邦咨询：疫情影响，2022 年 iPhone 14 系列出货量滑至 7,810 万支
40 |
41 | 富士康（Foxconn）郑州厂自 10 月起至今持续受疫情影响，稼动率仍难突破七成，而 10 月底正值苹果（Apple）新机销售的冲刺期，其中 Pro 系列因受市场青睐而持续调升生产比重，使得作为 Apple Pro 系列主力组装厂的富士康备感压力，即便有富士康深圳厂支持生产，但仍缓不济急，故 TrendForce 集邦咨询下调 2022 年 iPhone 14 系列出货量至 7,810 万支。
42 |
43 | ### 富士康独供地位不再，立讯确定将加入 iPhone 15 Pro Max 生产行列
44 |
45 | 富士康长年稳站 Pro 系列的独家组装，但苹果基于风险控管，原本即有意找寻其他业者加入生产组装行列，并且在 iPhone 14 Pro 系列上试行，富士康由于疫情影响稼动率，这也让立讯精密（Luxshare）成为 iPhone 15 Pro Max 组装供应链行列之一，目前其 iPhone 代工厂仍坐落中国，越南厂则是以苹果周边为主，目前尚无 iPhone 产线规划。
46 |
47 | ## 提案
48 |
49 | ### 正在审查的提案
50 |
51 | [SE-0383](https://github.com/apple/swift-evolution/blob/main/proposals/0383-deprecate-uiapplicationmain-and-nsapplicationmain.md "SE-0383") **弃用 @UIApplicationMain 和 @NSApplicationMain** 提案正在审查。
52 |
53 | `@UIApplicationMain` 和 `@NSApplicationMain` 曾经是 iOS 和 macOS 应用程序分别为应用程序声明合成平台特定入口点的标准方式。 这些函数已经被 SE-0281 引入的 `@main` 属性淘汰了。 这个提议试图在 Swift 6 之前弃用这些可选的入口点属性，从而支持 @main。
54 |
55 | [SE-0384](https://github.com/apple/swift-evolution/blob/main/proposals/0384-importing-forward-declared-objc-interfaces-and-protocols.md "SE-0384") **导入已声明的 Objective-C 接口和协议** 提案正在审查。
56 |
57 | 该提案主要目的是通过减少对已声明的 Swift API 可见性的负面影响，来提高 Swift 中现有 Objective-C 库的可用性。希望可以用合成占位符类型来表示 Swift 中已声明的 Objective-C 接口和协议。
58 |
59 | ## Swift论坛
60 | 1) 讨论 [SE-0384：导入前向声明的 Objective-C 接口和协议](https://forums.swift.org/t/se-0384-importing-forward-declared-objective-c-interfaces-and-protocols/62392 "SE-0384：导入前向声明的 Objective-C 接口和协议")
61 |
62 | 2) 讨论 [Swift 6 语言模式的设计优先级](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408 "Swift 6 语言模式的设计优先级")
63 |
64 | Swift 6 重点领域
65 |
66 | Swift 语言工作组确定了三个重点领域，Swift 的系统改进将取决于源代码不兼容的更改。 涉及 Swift 6 源代码不兼容更改的提案应解决以下多个领域之一：
67 |
68 | 默认情况下的数据竞争安全性：默认情况下的数据竞争安全性是对只能在新语言版本中上演的模型的重大转变，但它有很大的回报，因为它使并发程序更容易正确编写。 Swift 6 将需要加强围绕 Sendable 和 actor-isolation 检查的语义，但可能还需要额外的更改或功能来使在该安全模型中工作更容易。
69 |
70 | 性能可预测性：Swift 提供了一种富有表现力的相当高级的编程模型，可以抽象掉不必要的细节。 然而，Swift 开发可能会遇到性能“悬崖”，其中一个小的变化可能会导致程序运行时性能意外下降（例如，由于写时复制数据类型的过度复制）或 Swift 工具的性能（ 例如，“表达式太复杂”错误）。Swift 6 可以考虑更改默认语言语义以提高性能可预测性，例如通过调整有关变量生命周期的规则，使某些带有运行时成本的功能选择加入而不是选择退出，或调整类型推断规则以启用 一个性能更好的类型检查器实现。
71 |
72 | 包生态系统的可扩展性：Swift 语言和社区的长期健康取决于拥有一个强大的包生态系统。 Swift 语言和包管理器可能需要进行调整，以便更轻松地扩展包生态系统。 例如，Swift 的模块系统可能会得到改进，以限制模块的实现依赖性对其客户端模块的影响，从而使模块和包更能适应变化。
73 |
74 | 3) 讨论 [Vapor：如何使用 async-http / Vapor 客户端获取响应 URL](https://forums.swift.org/t/vapor-how-to-get-response-url-using-async-http-vapor-client/62418 "Vapor：如何使用 async-http / Vapor 客户端获取响应 URL")
75 |
76 | 4) 讨论 [如何使用函数的返回值而不是使用@Binding 在视图之间传递数据？](https://forums.swift.org/t/how-can-i-use-return-values-from-functions-instead-of-using-binding-to-pass-data-between-views/62413 "如何使用函数的返回值而不是使用@Binding 在视图之间传递数据？")
77 |
78 | 5) 提议 [在闭包中隐式使用guard self](https://forums.swift.org/t/implicit-guarding-self-in-closures/62386 "在闭包中隐式使用guard self")
79 |
80 | 受 SE-0365 的启发：
81 |
82 | ```Swift
83 | { [guarded self] in
84 | dismiss()
85 | }
86 | ```
87 |
88 | 在这里 guard self 以确保 self（否则返回），这通常在这种情况下使用：
89 |
90 | ```Swift
91 | { [weak self] in
92 | guard let self else { return }
93 | dismiss()
94 | }
95 | ```
96 |
97 | 6) 讨论 [改变一个属性包装器](https://forums.swift.org/t/mutating-a-property-wrapper/62403 "改变一个属性包装器")
98 |
99 | Property wrapper 一个栗子：
100 |
101 | ```Swift
102 | @propertyWrapper
103 | public struct PropertyWrapper {
104 | public var projectedValue: Self {
105 | get { self }
106 | _modify { yield &self }
107 | }
108 |
109 | public var wrappedValue: Int {
110 | get { box.value }
111 | set { box.value = newValue }
112 | }
113 |
114 | private var box: Box
115 |
116 | public init(wrappedValue: Int) {
117 | self.box = Box(value: wrappedValue)
118 | }
119 |
120 | public mutating func needsCopyOnWrite() -> Bool {
121 | !isKnownUniquelyReferenced(&box)
122 | }
123 | }
124 |
125 | private final class Box {
126 | var value: Int
127 |
128 | init(value: Int) {
129 | self.value = value
130 | }
131 | }
132 | ```
133 |
134 | 如何使用：
135 |
136 | ```Swift
137 | struct Struct {
138 | @PropertyWrapper
139 | var property: Int
140 |
141 | var propertyWrapper: PropertyWrapper {
142 | get { _property.projectedValue }
143 | _modify { yield &_property.projectedValue }
144 | }
145 | }
146 |
147 | var s = Struct(property: 123)
148 |
149 | print(s.$property.needsCopyOnWrite()) // true
150 | print(s.propertyWrapper.needsCopyOnWrite()) // false
151 | ```
152 |
153 | 7) 讨论 [保持任务实例超出其主体执行的警告？](https://forums.swift.org/t/caveats-of-keeping-task-instance-beyond-its-bodys-execution/62400 "保持任务实例超出其主体执行的警告？")
154 |
155 | 8) 讨论 [SE-0379: Opt-in Reflection Metadata](https://forums.swift.org/t/returned-for-revision-se-0379-opt-in-reflection-metadata/62390 "SE-0379: Opt-in Reflection Metadata")
156 |
157 | 更改反射生成的默认行为:
158 |
159 | 该提案规定，在 Swift 6 语言模式下，反射的默认行为应该成为选择加入。 社区对提案的这一方面反应不一，许多开发人员担心这会对现有代码中普遍使用打印、镜像和其他基于反射的 API 产生影响。 关于支持“按使用量付费”模型和提供丰富的运行时设施之间的紧张关系，有很好的哲学讨论。 该提案建议通过使依赖反射的 API 在其参数中添加 Reflectable 约束来解决这种紧张关系。 然而，对于许多 API 来说，这是一个问题，特别是标准库设施，如打印和相关的字符串化功能，旨在尽最大努力处理任何值。 要求通过潜在的许多 API 层线程化通用约束只是为了添加一些日志记录或 printf 调试将是一个严重的强加。 但是，消除对这些约束的需求会使编译器没有面包屑来帮助开发人员制作所有需要的类型 Reflectable 或 Custom * StringConvertible；开发人员必须通过大量专门测试来发现和修复运行时影响。
160 |
161 | Language Workgroup 还注意到 Swift 项目先前尝试追溯更改运行时行为，特别是 SE-0083，它通过从运行时中删除 Foundation 类型桥接来简化动态转换行为。 当时的核心团队最终拒绝了该提议，因为考虑到该提议的动态性质，他们无法想出一种方法来评估对 Swift 生态系统的影响，并有足够的把握认为该变化不会造成过度破坏。 语言工作组对更改默认反射行为也有类似的担忧； 即使默认更改受语言版本限制，我们希望开发人员采用 Swift 6 以获得静态并发安全和其他更改的好处，并期望他们也审计项目的动态行为以防止意外的反射依赖项将是一个障碍 更新他们的语言版本模式。 如果没有评估更改默认设置对现实世界影响的计划，我们就不会接受这种更改。
162 |
163 | Reflectable 的本质和动态投射支持:
164 |
165 | 提案规定 Reflectable 和 Sendable 一样是一个标记协议； 然而，与真正的标记协议不同，约束的存在对运行程序可用的元数据类型具有真正的运行时影响。 此外，与遵循协议不同，反射元数据不能通过其定义模块之外的扩展追溯添加到类型中。 因此，尽管将其作为通用约束是一种很好的语言设计，但将其称为标记协议或协议似乎不太正确。
166 |
167 | 该提案还规定，程序员可以通过动态转换查询一个类型是否携带全反射元数据？ 可反射。 如果 Reflectable 是一个标记协议，那么它如何在完全通用的情况下工作还不清楚，因为尽管我们可能静态地将表达式 x 识别为？ 可反射的，不可能将 x 处理为？ T 表示在运行时绑定到 Reflectable 存在类型的泛型类型参数 T。 但是，语言工作组还认为，在新的 Reflection 库中将此功能表达为独立的查询功能可能会更好，这样可以降低它必须与整个动态转换基础结构进行交互的复杂性。
168 |
169 | 现在的语言中存在一个非协议泛型约束——AnyObject 约束，只有类和没有见证表的类存在性才能满足。 编译器在内部将其归类为“布局约束”，因为它不需要明确的一致性，但其布局本质上满足约束要求的类型会隐式满足它。 目前还有一些其他布局约束只为优化器实现以允许部分专门化，但其中一些，特别是按位可复制类型的约束，在 C++ 行话中称为“平凡”或“POD”，也可以浮出水面 在语言中。 Reflectable 可能也适合这个系列，因为当编译器设置为发出所有反射元数据时，它不需要明确的“一致性”； 虽然它不是专门针对类型值的布局的约束，但它确实对该类型的元数据布局施加了约束。
170 |
171 | 调试器支持:
172 |
173 | 需要进一步考虑的实现的一个方面是它与调试器的交互。 LLDB 的 Swift 支持目前严重依赖全反射元数据来提供完整的功能，语言工作组希望看到一个计划来确保调试支持可用
174 |
175 | ## 推荐博文
176 |
177 | [出行iOS用户端卡顿治理实践](https://juejin.cn/post/7176823567059779639 "出行iOS用户端卡顿治理实践")
178 |
179 | **摘要：** 这篇文章主要讲解该如何去做好卡顿治理。我们使用APP有时会遇到点击响应迟钝、页面跳转缓慢、滑动列表不流畅、卡死无响应，这些就是卡顿问题，它会影响用户体验，严重时会导致用户的流失，因此卡顿治理是非常重要的。
180 |
181 | [58同城iOS包大小治理工具解密](https://juejin.cn/post/7176441132447399993 "58同城iOS包大小治理工具解密")
182 |
183 | **摘要：** 本文通过58同城包大小治理的实践经验，来讲解如何解决混编环境下OC/Swift无用类、无用资源、重复资源等检测问题，同时结合业内常见的段迁移、链接时优化(LTO)等多种技术手段，来辅助App进行瘦身。
184 |
185 | [iOS卡顿监控探索与实践](https://juejin.cn/post/7181352292673650746 "iOS卡顿监控探索与实践")
186 |
187 | **摘要：** 这篇文章主要讲解如何监控卡顿，帮助开发者进一步解决卡顿问题。与用户交互的事件都是在主线程里处理的，但如果主线程无法响应用户的交互就会造成卡顿，卡顿时间比较长是非常影响App的功能和用户体验的，所以这也是一个非常值得重视的问题。
188 |
189 | ## 话题讨论
190 |
191 | **您觉得烟花应该被禁止吗？**
192 |
193 | 欢迎在文末留言参与讨论。
194 |
195 | ## 关于我们
196 |
197 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
198 |
199 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
200 |
201 |
202 |
203 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
204 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_23.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第十四期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 勇敢是即便知道好结局不会每每降临在我们身上，但也依然选择热爱和坚持。**Swift社区**会伴你一起，见证每一刻勇敢的光亮！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果iPhone 15 Pro硬件细节曝光，广大网友期待USB-C接口迎来普及
12 | >
13 | > Swift 论坛：讨论嵌套泛型的问题
14 | >
15 | > 推荐博文：iOS App 项目优化
16 | >
17 | > **话题讨论：**
18 | >
19 | > 生活中遇到的问题你会使用 chatGTP 寻找答案吗？
20 |
21 | ## 新闻和社区
22 |
23 | ### 苹果iPhone 15 Pro硬件细节曝光，广大网友期待USB-C接口迎来普及
24 |
25 | 苹果在欧美市场已被多个监管施压放弃Lighting接口改为USB-C接口，最新关于苹果 iPhone 15 Pro硬件细节爆料消息，似乎透露着苹果公司将将在自家产品正式放弃Lighting接口改为 USB-C 接口。从苹果 iPhone 15 Pro 真机图片来看，苹果 iPhone 15 Pro 开始使用USB-C接口。随着安卓手机厂商普遍采用 USB-C 接口，目前来看苹果公司在自家新品上采用 USB-C 接口，也是整个手机行业的大势所趋。
26 |
27 | 
28 |
29 | 除此之外，苹果 iPhone 15 Pro 硬件外观部分也更加圆润，同时音量键设计也改为电容式设计，后置摄像头的镜头模组也变得更加凸起，意味着苹果公司在新的 iPhone 15 Pro 机型镜头模组进行了升级。
30 |
31 | 
32 |
33 | 
34 |
35 | 总体来说，iPhone 15 Pro 大概率也将是 iPhone 14Pro 升级产品，相较前代机型，在细节部分进行了进一步的优化完善。来源: IT极客世界。
36 |
37 | ### 苹果也要“降本增效”？步亚马逊、Meta等公司后尘，大刀砍向员工
38 |
39 | 
40 |
41 | 在亚马逊、微软、谷歌等国际科技巨头们裁员后，苹果也被曝出裁员消息。2 月 17 日，《纽约邮报》援引知情人士报道，苹果公司在过去几天裁减了数百名合同未到期的外包合同工。
42 |
43 | 作为全世界最赚钱的公司之一，苹果公司曾在 2022 年公开宣称不会裁员，但将停止招聘。但随着 2022 年四季度不及预期的财报发布后，苹果还是动了裁员的念头。
44 |
45 | 据苹果公司发布 10-12 月份的季度业绩显示，其实现总净销售额 1171.54 亿美元，同比下滑 5% ，不仅低于市场预期的 1211.04 亿元，还创造了 2019 财年来首次营收同比下滑。iPhone、Mac、可穿戴设备等业务营收均出现不同程度的下滑，仅iPad业务的营收实现了同比增长。
46 |
47 | 为挽救业务，苹果一方面加大促销力度，于 2022 年 9 月开始在中国销售的 iPhone 14 系列，在上市不到半年后即推出“全系降价 600 元- 800 元”的促销活动。搁往年，苹果最新款降价一般都在六七月份。如今，裁员也成为“降本增效”的新选择。
48 |
49 | ## Swift论坛
50 |
51 | 1) 讨论[WebURL KeyValuePairs API](https://forums.swift.org/t/weburl-keyvaluepairs-api/63164 "WebURL KeyValuePairs API")
52 |
53 | 为了更容易地从 URL 组件读取/写入键值对，WebURL 0.5.0 将包含一个新的 KeyValuePairs 类型。 当前的 formParams 视图将在下一个次要版本中弃用和删除。
54 |
55 | 2) 讨论[将反射元数据划分为运行时和调试类别](https://forums.swift.org/t/partition-the-reflection-metadata-to-runtime-and-debug-categories/63163/1 "将反射元数据划分为运行时和调试类别")
56 |
57 | 目前的情况：
58 |
59 | * 可以完全启用或禁用反射功能。 （中间没有选项）
60 | * 当使用 `-disable-reflection-metadata` 标志禁用时，LLDB 将无法使用反射元数据，从而导致调试功能显着降低。
61 | * 启用后，dsymutil 将反射信息从 TEXT 复制到 dSYM 的 DWARF 段，这允许 lldb 稍后发现它。
62 | * 通过使用 `-enable-reflection-for-debugger-only` 标志，LLDB 可以使用反射，但是，它不会链接到 NTD，这将允许链接器通过 dead-stripping 消除它。
63 |
64 | 设计：
65 |
66 | 快速编译器：
67 |
68 | * 扩展 FieldTypeMetadataBuilder（可能还有其他构建器）并使其可从外部进行配置。
69 |
70 | * 在 emitFieldDescriptor 中实例化两个 FieldTypeMetadataBuilder，一个将直接在 _DWARF 中发射全反射，另一个将像往常一样发射反射到 _TEXT 段。 前者将由 -g 系列标志控制，而后者将由反射标志控制。
71 |
72 | DSYMUTIL：
73 |
74 | * 更改 dsymutil，而不是从 TEXT 复制反射，而是将其复制到 DWRAF 段。
75 |
76 | LLDB：
77 |
78 | * 可能需要更改 LLDB，以教会它在没有提供 DSYM 的情况下进行调试时发现 DWARF 段中的反射。
79 |
80 | 3) 讨论[防止优化 XCFramework 所需的公共接口（又名 dyld：未找到符号）](https://forums.swift.org/t/prevent-optimizing-away-public-interfaces-needed-by-an-xcframework-aka-dyld-symbol-not-found/63162 "防止优化 XCFramework 所需的公共接口（又名 dyld：未找到符号）")
81 |
82 | 4) 提议[SE-0388：便捷 Async[Throwing]Stream.makeStream 方法](https://forums.swift.org/t/se-0388-convenience-async-throwing-stream-makestream-methods/63139 "SE-0388：便捷 Async[Throwing]Stream.makeStream 方法")
83 |
84 | 便捷 Async[Throwing]Stream.makeStream 方法”的审查现在开始，一直持续到 2023 年 2 月 26 日。
85 |
86 | 该提案可在此处获得：https://github.com/apple/swift-evolution/blob/main/proposals/0388-async-stream-factory.md
87 |
88 | 5) 讨论[Swift 开发容器模板](https://forums.swift.org/t/swift-devcontainer-template/63161 "Swift 开发容器模板")
89 |
90 | **内容大概：**
91 |
92 | Visual Studio Code 的优势之一是您可以在 docker 容器内开发项目。 如果你在 macOS 上开发但部署到 Linux，你不再需要在 Linux 上运行你的代码来验证它是否工作，你可以在你的 Mac 上编辑、编译、运行和调试你的项目，在 VS Code 中运行的 docker 容器中。
93 |
94 | 到目前为止，您可以通过手动编辑 devcontainer.json 文件或下载由 Microsoft 管理的快速开发模板来定义容器环境。
95 |
96 | 由 Microsoft 管理模板意味着在需要对模板进行更改时需要他们的输入（通过 PR 审查），例如添加新版本的 swift。
97 |
98 | 最近这种情况发生了变化，Swift devcontainer 模板的责任已转移到 SSWG。 devcontainer 现在存储在 swift-server GitHub 组织中。
99 |
100 | 我们做的第一件事是使模板现代化。 我们用等效的 devcontainer common-utils 功能替换了原始模板具有的 shell 脚本。 您可以在此处找到有关 `devcontainer` 功能的更多信息。原始模板有一个安装 Node.js 的选项（在大多数模板中实现的标准 MS）。 这已被删除，因为现在可以通过 devcontainer 功能完成。
101 |
102 | **新的 devcontainer GitHub链接**：https://github.com/swift-server/swift-devcontainer-template
103 |
104 | 6) 提问[嵌套泛型的问题](https://forums.swift.org/t/nested-generic-trouble/63152 "嵌套泛型的问题")
105 |
106 | ```Swift
107 | protocol P {}
108 | struct S: P {}
109 |
110 | func foo(_ value: T) {
111 | print(type(of: value)) // S
112 | print(value) // S()
113 | bar(value)
114 | }
115 |
116 | func bar(_ value: S) { print("S call") }
117 |
118 | func bar(_ value: T) { print("P call") }
119 |
120 | func test() {
121 | let s = S()
122 | bar(s) // S call
123 | foo(s) // P call
124 | }
125 | ```
126 |
127 | calling bar 直接打印出预期的“S call”，但通过“foo”调用它会打印出意外的“P call”。我的期望是错误的？
128 | 有趣的是它在 C++ 中按预期工作。
129 |
130 | 7) 提议[Swift 异步算法提案：缓冲区](https://forums.swift.org/t/swift-async-algorithms-proposal-buffer/63155 "Swift 异步算法提案：缓冲区")
131 |
132 | **介绍：**
133 |
134 | 缓冲是一种通过临时存储元素来平衡生产和消耗率波动来平衡供需的技术。 `AsyncStream` 通过允许您控制缓冲区的大小和处理超过该大小的元素的策略来促进此过程。 但是，这种方法可能并不适合所有情况，并且它不提供一种方法来调整其他 `AsyncSequence` 类型以合并缓冲。
135 |
136 | 该提案提出了一种新类型，可以满足这些更高级的要求，并为异步序列中的缓冲提供全面的解决方案。
137 |
138 | 8) 提议[自定义 Actor 执行器](https://forums.swift.org/t/pitch-custom-actor-executors/63135 "自定义 Actor 执行器")
139 |
140 | **介绍：**
141 |
142 | 该提案侧重于使 actor 执行程序可由库作者或最终用户配置的最小可行部分。 它基于 `@John_McCall` 的自定义执行器 16 的早期草案，我们在 Swift 并发性首次引入时分享了该草案，但我们从未正式确定它引入的想法。
143 |
144 | 在过去的几年里，我们发现了什么有效，什么需要更多的思考。 该提案侧重于标准化基本的 `SerialExecutor` 机制以及参与者如何自定义他们想要运行任务的位置。 我们也承认之前提出的未来工作领域，我们不打算在本提案中一次解决所有这些问题； 请参阅“未来方向”部分以了解更多信息。 有趣的是，这个 API 的某些部分被默默地引入并融入了 Swift 并发的 ABI——在适用的情况下，我们解释了这些关系以及我们如何使提议的 API 满足那些现有的要求。
145 |
146 | 这个推介也与最近推介的 `unsafeAssumeMainActor` 想法有一点关系，因为它打开了共享同一个串行执行器的各种参与者的领域，并引入了基于此的断言。
147 |
148 | **附上 GitHub 链接**：https://github.com/ktoso/swift-evolution/blob/wip-custom-executors/proposals/nnnn-custom-actor-executors.md
149 |
150 | ## 推荐博文
151 |
152 | [百度 APP iOS 端内存优化-原理篇](https://juejin.cn/post/7197970175478464571 "百度 APP iOS 端内存优化-原理篇")
153 |
154 | **摘要：** 本文介绍了 Mach 虚拟内存的特点、内存管理的数据结构以及 Mach 内核提供的内存操作接口，同时对 OC 内存分配核心函数 alloc 做了源码分析。
155 |
156 | [iOS 包体积优化3 - 代码管理](https://juejin.cn/post/7185083491061596219/ "iOS 包体积优化3 - 代码管理")
157 |
158 | **摘要：** 本文是 iOS 包体积优化的系列文章中代码管理模块，主要讲述了如何做好项目中的代码管理工作。
159 |
160 | [iOS 包体积优化5 - 编译优化](https://juejin.cn/post/7185101900303728695 "iOS 包体积优化5 - 编译优化")
161 |
162 | **摘要：** 本文是 iOS 包体积优化的系列文章中编译优化模块，介绍了多种项目实战所用到的编译优化方法。
163 |
164 | ## 话题讨论
165 |
166 | **生活中遇到的问题你会使用 chatGTP 寻找答案吗？**
167 |
168 | 123
169 |
170 | 欢迎在文末留言参与讨论。
171 |
172 | ## 关于我们
173 |
174 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
175 |
176 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
177 |
178 |
179 |
180 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
181 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_28.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第十九期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 用鞭子抽打，陀螺才会旋转。览**Swift社区**，技能方可升华！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：外媒：iPhone 的平均售价直逼 1000 美元创历史新高
12 | >
13 | > 提案：`Never` 遵守 `Codable`
14 | >
15 | > Swift 论坛：讨论在函数参数列表中使用 $ 进行绑定
16 | >
17 | > 推荐博文：抖音 Swift 编译优化
18 | >
19 | > **话题讨论：**
20 | >
21 | > 你认为AI会取代软件工程师吗？
22 |
23 | ## 新闻和社区
24 |
25 | ### 外媒：iPhone 的平均售价直逼 1000 美元创历史新高
26 |
27 | 近日根据调研公司公布的数据显示，全球智能手机市场表现整体下行，不过高端手机近三年同比都呈现增长趋势，尤其是 600 美元以上的机型。市场研究机构 CIRP 的数据报告显示在 2023 年第一季度 iPhone 的平均售价达到 988 美元 ( 约合人民币 6837 元 ) ，同比增长 12%，创历史新高，其中 iPhone 14 Pro 以及 iPhone 14 Pro Max 是 iPhone 系列最受欢迎的型号，虽然两款手机价格相对较高，但还是占据了总销量的近一半。去年同期 iPhone 的平均售价为 882 美元，2021 年的收尾价为 847 美元。
28 |
29 | 
30 |
31 | 相比之下 iPhone 14 的两款入门款机型的表现平平，而且跟上一代机型基本相同，大家宁愿买 iPhone 13 也不愿意买 iPhone 14。此外，用户对于手机存储空间的需求也在增加，导致更多人选择了更高容量的手机，这也进一步提升了平均售价。
32 |
33 | ### 分析师：iPhone需求良好，苹果股价还能涨22%
34 |
35 | 根据 Refinitiv 的预期，苹果最新财季的每股收益预计为 1.43 美元，营收为 929.7 亿美元，暗示将同比下滑 4.4%。另据 FactSet 的估计，苹果最新财季 iPhone 的收入预计将同比下滑 3.8% 至 486.6 亿美元，且预计包括 iPhone 在内的每条硬件产品线都会出现同比下滑。
36 |
37 | 不过，Wedbush 高级分析师 Daniel Ives 在发给《每日经济新闻》记者的置评邮件中称，根据他们最近对亚洲供应链的调查，他们认为苹果周四盘后发布的财报中，iPhone 的营收应该至少与预期一致。
38 |
39 | “我们认为，尽管宏观形势不稳，但由于较高的平均售价和 iPhone14 Pro 的整体升级活动，以及 iPhone 本季度在关键的中国市场的需求明显上升，该产品线的营收可能会出现一些上升。随着本季度 App Store 营收的增长，我们认为苹果的服务收入应该是稳定的，结合起来应该转化为苹果的核心收入，至少应该符合市场预期，我们维持对苹果的‘跑赢大盘’评级和 205 美元的目标价。”这意味着，苹果较周三收盘价 167.45 美元还有 22% 的上涨空间。
40 |
41 | “苹果在中国的市场份额正在增加，美国和欧洲的需求也保持良好，我们估计目前约有 25% 的 iPhone 用户在过去四年多的时间里没有换过新机。由于备受期待的周年纪念版iPhone 15 将于 9 月份发布，从 iPhone 14 到 iPhone 15 的过渡看起来将比过去的 iPhone 换代周期更加稳定。我们还认为，iPhone 的平均售价将升至 900 美元 ~ 925 美元左右，这将是下一个 iPhone 周期一个值得关注的趋势。”Daniel Ives补充道。
42 |
43 | ### 准备好迎接即将在 5 月 9 日推出的增强全球定价机制
44 |
45 | 借助 App Store 世界级的商务和支付系统，你能够便捷高效地为国际市场设定均衡的价格，根据外汇汇率或税费的变化进行调整，还可以管理每个店面的价格。上个月，我们推出了重大定价机制升级，其中包括将增强全球定价机制的适用范围扩展至所有购买类型。如今，更新后的价格点将跟随各个国家或地区最常见的定价方式，并且将根据金融数据机构提供的公开汇率信息做调整，在全球范围内与你为基准店面设定的价格保持平衡，因此更适用于当地顾客。
46 |
47 | 谨此提醒，自 2023 年 5 月 9 日起，App Store 各店面的现有 App 和一次性 App 内购买项目的价格都将以产品当前在美国店面的价格为基础进行更新，除非你在 2023 年 3 月 8 日后进行了相关更新。你随时可以使用 App Store Connect 或 App Store Connect API 更新基准店面的国家或地区。如果你选择进行更新，在 App Store 根据外汇变化或新的税费生成全球均衡价格时，你所选基准店面的价格将不会受到调整。你还可以选择手动调整多个所选店面中的价格，而不使用均衡的价格。
48 |
49 | ## 提案
50 |
51 | ### 通过的提案
52 |
53 | [SE-0391](https://github.com/apple/swift-evolution/blob/main/proposals/0391-package-registry-publish.md "SE-0391") **Package Registry 公开发布** 提案通过审查。该提案已在 **二十四期周报** 正在审查的提案模块做了详细介绍。
54 |
55 | [SE-0394](https://github.com/apple/swift-evolution/blob/main/proposals/0394-swiftpm-expression-macros.md "SE-0394") **Package Manager 支持自定义宏** 提案通过审查。该提案已在 **二十七期周报** 正在审查的提案模块做了详细介绍。
56 |
57 | ### 正在审查的提案
58 |
59 | [SE-0396](https://github.com/apple/swift-evolution/blob/main/proposals/0396-never-codable.md "SE-0396") **Never 遵守 Codable** 提案正在审查。
60 |
61 | 该提案主要介绍 `Never` 扩展，使其符合 `Encodable` 和 `Decodable` 协议，一起称为 `Codable`。
62 |
63 | [SE-0397](https://github.com/apple/swift-evolution/blob/main/proposals/0397-freestanding-declaration-macros.md "SE-0397") **独立声明 Macros** 提案正在审查。
64 |
65 | 该提案概括了为 Expression Macros 引入的 `#` -prefixed 宏扩展语法，允许宏生成声明，支持许多其他用例，包括：
66 |
67 | * 从模板或其他数据格式（例如 JSON）生成数据结构。
68 | * 将 SE-0196 中引入的 `#warning` 和 `#error` 指令作为宏。
69 |
70 | [SE-0398](https://github.com/apple/swift-evolution/blob/main/proposals/0398-variadic-types.md "SE-0398") **允许泛型类型对包进行抽象声明** 提案正在审查。
71 |
72 | 之前的 SE-0393 引入了 Value 和 Type 参数包和几个相关概念，允许泛型函数声明抽象出可变数量的类型。该提案将这些想法概括为泛型类型声明。
73 |
74 |
75 | ## Swift论坛
76 |
77 | 1) 讨论[避免未使用的异步结果的可发送警告](https://forums.swift.org/t/avoiding-sendable-warning-for-unused-async-result/64633 "避免未使用的异步结果的可发送警告")
78 |
79 | **内容大概**
80 |
81 | 有一个独立于专用 actor 的功能：
82 |
83 | ```Swift
84 | @globalActor
85 | final class SomeDedicatedActor {
86 | actor Actor {}
87 | static let shared = Actor()
88 | }
89 |
90 | @SomeDedicatedActor
91 | func f() async -> [Any] {
92 | // ...
93 | }
94 | ```
95 |
96 | 我们通常从与@SomeDedicatedActor 隔离的其他函数调用 f()，但我们有一个调用是我们想从不同的 actor 进行的。
97 |
98 | 我们做这个调用纯粹是为了 f 的副作用，根本不关心返回结果。 我希望以下构造是有效的，但是通过 Targeted/Complete Sendable 检查，我们会收到警告：
99 |
100 | ```Swift
101 | @MainActor
102 | func g() async {
103 | // Non-sendable type '[Any]' returned by implicitly asynchronous call
104 | // to global actor 'SomeDedicatedActor'-isolated function cannot cross
105 | // actor boundary
106 | _ = await f()
107 | }
108 | ```
109 |
110 | 如果不使用 Swift 会忽略跨角色边界传输结果是否合理？
111 |
112 | * 如果是这样，那么这只是一个虚假的警告，还是这个构造现在实际上是不安全的（因为该值确实强行跨越参与者边界）？
113 | * 如果不是，是否有理由必须跨界传输结果？
114 |
115 | **回答**
116 |
117 | 如果该值是不可发送的，它可能具有只允许在其原始 actor 中发生的 deinit 效果。 因此，忽略结果实际上必须“避免返回”actor 的结果，因为它必须在离开 actor 的隔离上下文之前销毁该值。 这对我来说似乎相当微妙，但也许它与编写一个返回非 Sendable 类型的隔离方法是一致的，因为您永远无法使用隔离之外的结果。
118 |
119 | 2) 讨论[在函数参数列表中使用 $ 进行绑定](https://forums.swift.org/t/using-for-binding-in-function-parameter-list/64645 "在函数参数列表中使用 $ 进行绑定")
120 |
121 | **内容大概**
122 |
123 | 最近发现可以像这样在闭包参数中使用 $ 变量名：
124 |
125 | ```Swift
126 | Bind("Title") { $title in
127 | TextField(title, text: $title)
128 | }
129 | ```
130 |
131 | 然而，对于像这样的函数参数来说，同样的事情似乎是不可能的：
132 |
133 | ```Swift
134 | func foo(title $title: Binding) {
135 | TextField(title, text: $title)
136 | }
137 | ```
138 |
139 | 但是编译器在函数声明处给出了一个错误：
140 |
141 | ```Swift
142 | Cannot declare entity named '$title'; the '$' prefix is reserved for implicitly-synthesized declarations
143 | ```
144 |
145 | **回答**
146 |
147 | 您需要在参数上使用属性包装器。
148 |
149 | ```Swift
150 | func foo(@Binding title: String) {
151 | TextField(title, text: $title)
152 | }
153 |
154 | foo($title: .constant("R.I.P. Taylor Hawkins 🥁"))
155 | ```
156 |
157 | 3) 讨论[Task - 等待变量更改](https://forums.swift.org/t/task-awaiting-for-variable-change/64626 "Task - 等待变量更改")
158 |
159 | **内容大概**
160 |
161 | 在使用 Task 时有一个如何解决问题的建议。
162 | 在等待 Task 内部的一些变量更改以进一步移动。
163 |
164 | 意思是说：
165 |
166 | ```Swift
167 | Task {
168 | ... for example here comes some complex code that is sending requests
169 | through web socket to outer world,
170 | response from websocket will change the variable result on this clas
171 | but out of this scope
172 |
173 | // with this line we are waiting for variable change with reasonable timeout
174 | do {
175 | try await @change(variable: self.result, timeout:10 sec)
176 | } catch {
177 | ... timeout
178 | print("we are waiting too long for server response")
179 | }
180 | }
181 | ```
182 |
183 | **回答**
184 |
185 | 您目前可以使用异步序列解决此问题。 现在的一个常见模式是执行以下操作：
186 |
187 | ```Swift
188 | static func main() async {
189 | var cont = AsyncStream.Continuation!
190 | let stream = AsyncStream { cont = $0 }
191 | let continuation = cont
192 |
193 | setupWebsocket(continuation)
194 |
195 | for await element in stream {
196 | // process the result
197 | }
198 | }
199 |
200 | func setupWebsocket(continuation: AsyncStream.Continuation) {
201 | // Setup the web socket and at some point call the following code
202 | continuation.yield(2) // Yield your result
203 | }
204 | ```
205 | 另一件可能对这里有帮助的事情是当前正在发生的 Observation pitch，这将允许你观察类并让 Task 改变它； 然而，重要的是你需要确保一切都是线程安全的。
206 |
207 | 4) 更新 [Foundation 的下一步计划 - 2023 年 4 月更新](https://forums.swift.org/t/whats-next-for-foundation-april-2023-update/64637 "Foundation 的下一步计划 - 2023 年 4 月更新")
208 |
209 | 链接：https://www.swift.org/blog/future-of-foundation/
210 |
211 | 更多相关的详细信息链接：https://www.swift.org/blog/foundation-preview-now-available/
212 |
213 | 5) 更新 [Swift Evolution Dashboard 支持即将推出的 Feature Flags](https://forums.swift.org/t/swift-evolution-dashboard-support-for-upcoming-feature-flags/64617 "Swift Evolution Dashboard 支持即将推出的 Feature Flags")
214 |
215 | Swift Evolution Dashboard 现在包括对即将推出 Feature Flags 的支持。
216 |
217 | Swift 5.8 引入了使用新编译器选项启用即将推出的功能的能力：-enable-upcoming-feature 后跟即将推出的功能的名称。
218 |
219 | 这些即将到来的特征标识符被称为即将到来的特征标志或简称 UFF。（详见 SE-0362 1）
220 |
221 | 随着 Dashboard 的更新，您现在可以轻松找到所有带有即将推出的功能标志的提案以及用于每个功能的标志名称。
222 |
223 | 您可以使用 Swift Evolution 仪表板来：
224 |
225 | * 查看提案的 UFF（如果有的话）
226 | * 按名称搜索 UFF
227 | * 过滤以查看所有带有 UFF 的提案
228 | * 新的 UFF 过滤器按钮与现有的搜索字段和状态过滤器结合使用。
229 |
230 | ## 推荐博文
231 |
232 | [SwiftUI 中的 Deeplink URL 处理](https://www.avanderlee.com/swiftui/deeplink-url-handling/ "SwiftUI 中的 Deeplink URL 处理")
233 |
234 | **摘要：** 本文讨论深度链接（ deeplinks ）以及如何在 SwiftUI 中配置应用程序来处理它们。深度链接允许用户通过打开特定位置，在启动后深入进入您的应用程序，例如基于所点击的链接打开某个菜谱或电影等。本文提供了在 Xcode 中配置URL类型和使用视图修饰符或 AppDelegate/SceneDelegate 方法处理传入 URL 的步骤。此外，它建议使用深度链接进行其他场景，例如使用特定账户登录或在预发布和生产环境之间切换。该文章还强调了考虑安全性时定义支持 Deeplink URL 的重要性。
235 |
236 | [抖音 Swift 编译优化 - 基于自定义 Toolchain 编译提速 60%](https://juejin.cn/post/7221444501956886588 "抖音 Swift 编译优化 - 基于自定义 Toolchain 编译提速 60%")
237 |
238 | **摘要：** 本篇博客主要介绍了抖音团队基于自定义 Toolchain 提出的 Swift 编译优化方案，重点讨论在全部模块化后解决依赖瓶颈所采用的方法以及优化效果。通过裁剪 Clang Header 指定内容来降低 OC 头文件预编译耗时，并采用细粒度控制方案，实现编译提速 60%。文章还分享了方案拆解、快速验证、开发调试、验证上线等具体流程，对于有需要进行Swift编译优化的读者可以参考此文中给出的思路和方法。
239 |
240 | [Swift 最佳实践之 Property Wrapper](https://juejin.cn/post/7222189908429275173 "Swift 最佳实践之 Property Wrapper")
241 |
242 | **摘要：** 本文介绍了 Swift 5.1 中引入的 Property Wrapper，它是对属性的一层封装，隐藏与属性相关的逻辑细节从而提高代码复用性。文章详细讲解了 Property Wrapper 的定义、使用、初始化以及 Projected Value 等概念，并通过示例展示了在 SwiftUI、线程安全保护、Codable 和 User Defaults 存储等方面应用 Property Wrapper 的方法和好处。最后还指出了使用 Property Wrapper 标记属性时需要注意的限制。
243 |
244 | ## 话题讨论
245 |
246 | **你认为AI会取代软件工程师吗？**
247 |
248 | 1、会
249 | 2、不会
250 |
251 | 欢迎在文末留言参与讨论。
252 |
253 |
254 | ## 关于我们
255 |
256 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
257 |
258 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
259 |
260 |
261 |
262 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
263 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_3.md:
--------------------------------------------------------------------------------
1 |
2 | ## 前言
3 |
4 | 本期周报开始，将会引入**推荐博文**模块，主要为大家分享展示优秀的 iOS 技术博文，如果大家阅读到优秀的文章欢迎在文末留言告诉小编，大家资源共享共同进步。
5 |
6 | iPhone 13 新品上架，你们都买了吗？苹果声称，iPhone 13 拥有全新的双摄像头系统，采用超快的 `A15` 芯片，提高电池的续航能力。
7 |
8 | 我们不仅要关注新的 iPhone 13，几天前，`Xcode 13` 与 [Swift 5.5](https://forums.swift.org/t/swift-5-5-released/52247 "Swift 5.5") 也一起发布了。这是 Swift 5.5 更新的[列表](https://twitter.com/simjp/status/1440318174856036354 "列表")，这个版本发布了很多新功能。Xcode 13 的发布说明可以在这里找到：[iOS & iPadOS 15 Release Notes](https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-15-release-notes "iOS & iPadOS 15 Release Notes")。
9 |
10 | 现在已经开始将**并发**功能向后部署到旧的 Swift 版本上。
11 |
12 | > 为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与**周报编辑**，同时邀请赞助商对我们平台赞助支持。
13 |
14 | ## 新闻和社区
15 |
16 | **Cory Benfield** 告诉我们 [Swift Crypto 2.0.0 已经发布](https://forums.swift.org/t/swift-crypto-2-0-0/52308 "Swift Crypto 2.0.0")。
17 |
18 | ## 入门任务
19 |
20 | **SR-15218**: [Compiler] [增强 CGFloat/Double 之间的可互转，允许 optional 之间的互转](https://bugs.swift.org/browse/SR-15218 "Enhance interchangeable CGFloat/Double to allow interchange between optional")
21 |
22 | ## Commits 和 pull requests
23 |
24 | **salinas-miguel** 的 PR 已合并：[删除了 Swift 项目对 macOS 上的 Foundation 的依赖](https://github.com/apple/swift/pull/39216 "Remove Foundation dependency")。
25 |
26 | Doug Gregor 创建了一个 `pull request` [对 Swift 向后部署支持并发](https://github.com/apple/swift/pull/39342 "Back-deployment support for Swift concurrency")。
27 |
28 | ## 正在审查的提案
29 |
30 | **SE-0323**：[Asynchronous Main 语义](https://forums.swift.org/t/se-0323-asynchronous-main-semantics/52022 "Asynchronous Main Semantics") 正在审查中。
31 |
32 | 程序设置通常发生在 `main` 函数中，开发人员希望在程序的其他部分运行之前执行操作。`Objective-C`、`c++` 和 `C` 都有初始化，这些初始化在 `main` 入口点执行之前运行，并且可以与 Swift 的并发系统交互。在 Swift 并发模型中，开发人员编写的异步 `main` 函数被包装在一个任务中，并在 `main` 入口点运行时被放入到主队列中。如果初始化时在主队列中插入了一个任务，那么该任务可能会在 `main` 函数之前执行，所以设置是在初始化任务运行之后执行的。
33 |
34 | **SE-0324**：[对 C 函数的指针参数放宽诊断](https://forums.swift.org/t/se-0324-relax-diagnostics-for-pointer-arguments-to-c-functions/52019 "Relax diagnostics for pointer arguments to C functions")正在审查中。
35 |
36 | `C` 有特殊的指针别名规则，例如允许 `char *` 为其他指针类型别名，并允许指向有符号和无符号类型的指针别名。 某些 `C` `API` 的可用性依赖于在这些规则的边界内轻松转换指针的能力。 Swift 通常不允许类型化指针转换。请参阅[SE-0107 UnsafeRawPointer API](https://github.com/apple/swift-evolution/blob/main/proposals/0107-unsaferawpointer.md "UnsafeRawPointer API")。让 Swift 编译器在调用从 `C` 头文件导入的函数时允许在 `C` 规则内进行指针转换将显著提高互操作性，而不会对类型安全产生负面影响。
37 |
38 | ## Swift 论坛
39 |
40 | **Ashley Garland** 介绍一些新实验出来的 [Swift Package Manager 代码段](https://forums.swift.org/t/swift-snippets/51947 "Swift Snippets")。
41 |
42 | 我们都知道通过示例学习是很棒的，尤其是对于代码。 我想创建最小、最简单的方法来为 `Swift packages` 提供示例代码，我刚刚在 [Swift Package Manager](https://github.com/apple/swift-package-manager/commit/a0ffd92a2c80f2c4677d696e248f4cfbec9d6540 "Swift Package Manager") 中完成了一些正在进行的工作。
43 |
44 | **Filip Sakel** 提出了一项[改进 Property-wrapper-related 的初始化](https://forums.swift.org/t/pitch-refining-property-wrapper-related-initialization/52049 "Refining Property wrapper related Initialization")的提案。
45 |
46 | [SE 0258](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md "SE 0258") 引入了 `property wrappers`，[SE 0293](https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md#detailed-design "SE 0293") 使用类似函数的声明对其进行了扩展。 今天，`property wrappers` 初始化由于其日益增长的多功能性而表现出不一致。 具体来说，成员初始化使用复杂的、记录不足的规则，并且 `projection` 初始化仍然有限。该提案将简化具有包装属性的类型的合成成员初始化，并扩展 `projection` 值初始化以包括全局、类型和局部包装属性。
47 |
48 | **Jordan Rose** 开始讨论[删除 Optional 变量的隐式初始化](https://forums.swift.org/t/pre-pitch-remove-the-implicit-initialization-of-optional-variables/52300 "remove the implicit initialization of Optional variables")。
49 |
50 | 在 Swift 6 中，可选变量与所有其他变量一样，默认情况下不会初始化。 局部变量和全局变量得到修复，添加 `= nil`。 属性仅在附加到有关未初始化变量的错误的注释中修复，这显然不是正确的做法，只有 Swift 5 中需要这么做。 不过，迁移者也可以自动应用该修复程序。
51 |
52 | ## 推荐博文
53 |
54 | ### iOS 系列
55 |
56 | [如何在 Swift 中实现状态机？](https://mp.weixin.qq.com/s/vkbN_d3tR_Ym_gJYBVGCOw)
57 |
58 | 简言之：我们通常称作的状态机是有限状态机的简称，它是一种**数学计算模型**。
59 |
60 | [避免 Swift 单元测试中的强制解析](https://mp.weixin.qq.com/s/DawFZMOuU5jbaw0Bi0gOhw)
61 |
62 | 强制解析（使用 `!`）是 Swift 语言中不可或缺的一个重要特点（特别是和 Objective-C 的接口混合使用时）。它回避了一些其他问题，使得 Swift 语言变得更加优秀。
63 |
64 | [iOS 识别虚拟定位调研](https://mp.weixin.qq.com/s/ZbZ4pFzzyfrQifmLewrxsw)
65 |
66 | 最近业务开发中，有遇到我们的项目 app 定位被篡改的情况，在 android 端表现的尤为明显。为了防止这种黑产使用虚拟定位薅羊毛，iOS 也不得不进行虚拟定位的规避。
67 |
68 | ### 实时文讯
69 |
70 | [Xcode 13 更新了哪些内容](https://mp.weixin.qq.com/s/DwClglO_fOYDfLsINU_hdw)
71 |
72 | [开发者需要了解的 iOS 15](https://mp.weixin.qq.com/s/E5vTD9QDgKfVErWxCv4wjg)
73 |
74 | [Xcode 13 正式版发布，来看看有什么新特性](https://mp.weixin.qq.com/s/4OGxPn-dgDc-jjtM-DtqGQ)
75 |
76 |
77 | ### SwiftUI 系列
78 |
79 | [为什么 SwiftUI 的修饰符顺序很重要](https://mp.weixin.qq.com/s/K_i8bvcaHDfVMUsQTv3MOw)
80 |
81 | 每当我们将修饰符应用于 `SwiftUI` 视图时，我们实际上都会创建一个，应用了更改的新视图 —— 我们不仅仅是修改现有的视图。
82 |
83 | [为什么 SwiftUI 的视图使用结构体](https://mp.weixin.qq.com/s/gSeFOMrjze6KE_X6WwWAZQ)
84 |
85 | 如果您曾经为 `UIKit` 或 `AppKit`（Apple 的 iOS 和 macOS 原始用户界面框架）编程，您会知道它们使用类而非结构体来构造视图。`SwiftUI` 更喜欢将结构体用于整体视图。
86 |
87 | [如何结合 Core Data 和 SwiftUI](https://mp.weixin.qq.com/s/ZQSbu7dzwC-XbGcUcBkjAw)
88 |
89 | `SwiftUI` 和 `Core Data` 之间相差将近十年。尽管时间相距遥远，Apple 还是投入了大量工作以确保这两种强大的技术能够完美地相互配合使用，这意味着 `Core Data` 就像始终以这种方式设计一样，已集成到 SwiftUI 中。
90 |
91 |
92 | ## 关于我们
93 |
94 | 公众号是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。欢迎关注公众号：**Swift社区**，后台点击进群，联系我们获取更多内容。
95 |
96 |
97 |
98 |
99 | 感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。周报仓库：https://github.com/SwiftCommunityRes
100 |
101 | 后续还会翻译大量资料到我们公众号，有感兴趣的朋友，可以加入我们，扫码添加微信
102 |
103 |
104 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_4.md:
--------------------------------------------------------------------------------
1 |
2 | ## 前言
3 |
4 | 最近 Swift.org 进行了一些非常好的改进，包括对 `dark mode` 的支持。 对于在 iOS 上使用 `dark mode` 的用户，该网站将自动切换模式以匹配。
5 |
6 | > 为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与**周报编辑**，同时邀请赞助商对我们平台赞助支持。
7 |
8 | ## 入门任务
9 |
10 | **SR-15271** [Compiler] [当 CodingKeys 与属性不匹配时改进可编码诊断](https://bugs.swift.org/browse/SR-15271 "Improve Codable Diagnostics When CodingKeys Do Not Match Properties")
11 |
12 | ## 新闻和社区
13 |
14 | **Ted Kremenek** 写了一篇关于 [Swift 5.5 版本](https://swift.org/blog/swift-5-5-released/ "Swift 5.5 Released")的文章。
15 |
16 | **Bruno Rocha** 发表了一篇优秀的文章，解释了 [AsyncSequence 在 Swift 内部是如何工作](https://swiftrocks.com/how-asyncsequence-works-internally-in-swift "How AsyncSequence works internally in Swift")的。
17 |
18 | **Lee Kah Seng** 写了一篇文章，描述了 [Swift 中的 Actor Reentrancy 问题](https://swiftsenpai.com/swift/actor-reentrancy-problem/ "The Actor Reentrancy Problem in Swift")。
19 |
20 | **Amritpan Kaur** 解释了她如何参与首届 [Swift 导师，并致力于编译器开发和语言设计](https://forums.swift.org/t/swift-mentorship-compiler-language-design/52522 "Swift Mentorship - Compiler & Language Design")。
21 |
22 | ## Commits 和 pull requests
23 |
24 | **Michael Ilseman** 合并了一个为 [String 实现原生规范化](https://github.com/apple/swift/pull/38922 "[stdlib] Implement native normalization for String")的 pull request。
25 |
26 | **Doug Gregor** 创建了一个 pull request，[向后兼容 @objc actor 类型](https://github.com/apple/swift/pull/39609 "Back-deploy @objc actor types")。
27 |
28 | ## 同意的提案
29 |
30 | **SE-0322** [临时未初始化缓冲区](https://forums.swift.org/t/accepted-with-modifications-se-0322-temporary-uninitialized-buffers/52532 "Temporary Uninitialized Buffers")已接受修改。
31 |
32 | **SE-0323** [Asynchronous Main 语义](https://forums.swift.org/t/accepted-se-0323-asynchronous-main-semantics/52531 "Asynchronous Main Semantics")已接受。
33 |
34 | **SE-0324** 接受了[对 C 函数的指针参数放宽诊断](https://forums.swift.org/t/accepted-se-0324-relax-diagnostics-for-pointer-arguments-to-c-functions/52599 "Relax diagnostics for pointer arguments to C functions")提案。
35 |
36 | ## 正在审查的提案
37 |
38 | **SSWG-0017**：[MultipartKit](https://forums.swift.org/t/sswg-0017-multipartkit/52586 "MultipartKit") 正在审查中。
39 |
40 | `MultipartKit` 提供 `Multipart` 数据的低级解析和序列化，以及对 `Multipart` 表单数据的编码和解码的高级 `Codable` 支持。
41 |
42 | ## Swift 论坛
43 |
44 | **1. Karoy Lorentey** 询问什么时候将 `ManagedAtomic/UnsafeAtomic` 标记为 `Sendable`？
45 |
46 | 刚刚提交了[问题 #45](https://github.com/apple/swift-atomics/issues/45 "The constructs provided by this package need to be marked Sendable")，要求将 `UnsafeAtomic`、`ManagedAtomic` 和朋友标记为 `Sendable`，这反映了它们可以安全地跨并发域传输。
47 |
48 | **2. Kavon Farvardin** 提议定义 [actor 初始化器](https://forums.swift.org/t/proposal-actor-initializers-and-deinitializers/52322 "[proposal] Actor Initializers and Deinitializers")在 `Swift` 中的工作方式。
49 |
50 | 目前，本提案中描述的一些问题的建议解决方案通过警告反映在 `Swift 5.5` 中，但是审查 `Swift 6` 的这些更改很重要。此外，该提案为 `MainActor` 隔离类的 `deinit` 增加了额外的功能，这样可以更容易、更安全地编写。如果有新的想法和评论可以在[这里提出来](https://github.com/kavon/swift-evolution/blob/actor-init-proposal2/proposals/nnnn-actor-initializers.md "Actor Initializers and Deinitializers")。
51 |
52 | **3. Kelvin Ma** 发现 [Swift 5.5 存在严重的堆栈损坏错误](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344 "Swift 5.5 has serious stack corruption bugs!")。
53 |
54 | 我发现了几个与 async/await 相关的堆栈损坏错误，这些错误可以在使用最近的夜间工具链编译的简单测试程序中重现。 我已经确认 5.5-RELEASE 工具链中存在这些错误中的两个三四个。
55 |
56 | 我发现了几个与 `async/await` 相关的堆栈损坏错误，可以在 `recent nightly toolchains` 的简单测试程序中重现问题。**我已确认 `5.5-RELEASE toolchain` 中存在多个错误**。
57 |
58 | **4. Becca Royal-Gordon** 提出了在[Sendable 检查中添加暂存](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413 "Staging in Sendable checking")的建议。
59 |
60 | 几周前，**@Douglas_Gregor** [提出了一些更改](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341 "[Pitch] Staging in Sendable checking")，试图解决在一些客户端或依赖项可能尚未更新时在模块中采用 Sendable 检查所涉及的一些问题。当模块最终更新时，这种方法可能会出现问题和隐藏的 BUG，以及 `Objective-C` 库如何能够控制其类型的可发送性。
61 |
62 | **5. YR Chen** 开始讨论[解决 Swift 6 发布时的不一致问题](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437 "Upon Swift 6: Solve inconsistency within the language")。
63 |
64 | 一些 API 破损的语言设计可以在 3 年后 `Swift 6` 的发布中修复。这是一个相当长的时间，通过 `Swift 3.2` 和 `Swift 4.2` 事实证明，过渡到 Swift 突破性发布要顺畅的多。
65 |
66 | 建议我们选择一些延迟的断点，目的是消除语言中的不一致。这些想法已经得到了社区的积极反馈，但是还是没有开始实施。
67 |
68 | **6. Philippe Hausler** 提出了[定义 Clock, Instant, Date 和 Duration ](https://forums.swift.org/t/pitch-clock-instant-date-and-duration/52451 "[Pitch] Clock, Instant, Date, and Duration")的提案。
69 |
70 | **时间的概念可以分为三个不同的部分：**
71 |
72 | * 提供现在概念的项目加上一个在给定时间点后醒来的方法，* 时间点的概念
73 | * 时间测量的概念
74 |
75 | 这三项分别是时钟、瞬间和持续时间。时间的测量可用于许多类型的 API，从高级网络连接超时概念到休眠任务的时间量。目前，测量时间类型的 API 采用 `NSTimeInterval` 又名 `TimeInterval`、`DispatchTimeInterval`，甚至像 `timespec` 这样的类型。
76 |
77 | **7. Michael Ilseman** 提出了[实现声明性字符串处理](https://forums.swift.org/t/declarative-string-processing-overview/52459 "Declarative String Processing Overview") API 的想法。
78 |
79 | 字符串处理很困难，Swift 标准库目前提供的功能不足。我们建议添加两个新的声明性字符串处理 API，一个是熟悉的 `Regex` 文本，一个是更强大的 `Pattern` 结果生成器，以便 Swift 字符串处理起来更快速简便。
80 |
81 | 这是一个大型功能，最终将分为多个 `Swift Evolution` 提案。主要目的在于推动高级方向的讨论，并介绍该功能的关键点及其相互关系。
82 |
83 | **8. Kelvin Ma** 开始讨论[长期支持 (“LTS”) 版本](https://forums.swift.org/t/we-need-long-term-support-lts-releases/52462 "long-term-support (“LTS”) releases.")。
84 |
85 | 对于那些没有关注开发主题的人，@mickeyl，@timdecode，我最近在 `Swift 5.5` 发布工具链中发现了数量惊人的高危险的堆栈损坏 BUG。
86 |
87 | 撇开 `Swift 5.5` 中堆栈损坏问题的技术方面不谈，在我们发布周期中采用某种形式的[“长期支持”（LTS）版本8](https://forums.swift.org/t/we-need-long-term-support-lts-releases/52462 "“Long-Term Support” (LTS) release 8 ")的概念是否值得，就像 Ubuntu 一直以来所做的那样。
88 |
89 | **9. Anders Bertelrud** 提出了扩展插件 [SwiftPM 插件 API ](https://forums.swift.org/t/pitch-additional-api-available-to-swiftpm-plugins/52494 "pitch additional api available to swiftpm plugins")以提供更多上下文的提案。
90 |
91 | `SE-0303` 引入了 SwiftPM 插件，特别关注构建工具插件（尤其是那些生成源代码的插件）。为了保持该提案的界限，插件可用的信息类型和数量针对生成构建命令的任务。
92 |
93 | 在开始考虑新类型的插件之前，扩展所有类型插件可用的信息似乎是明智的。未来的提案可能会为特定类型的插件添加特定的 API，但在此之前，一个好的起点似乎是让所有插件访问 SwiftPM 内部已经拥有的包图的提炼形式。这应该允许任何特定插件有很大的自由度。
94 |
95 | 我提出一份提案草案，用于扩展可用于 SwiftPM 插件的 API，并且很想听听大家的想法。在 SwiftPM 存储库中的 PR 中有一个实现。
96 |
97 | **10. Guillaume Lessard** 提出了一项[扩大 withMemoryRebound 可用性](https://forums.swift.org/t/pitch-expand-usability-of-withmemoryrebound/52500 "expand usability of withMemoryRebound")的提案。
98 |
99 | 函数 `withMemoryRebound(to:capacity:_ body:)` 执行一个闭包，同时将一定范围的内存临时绑定到与被调用者绑定的类型不同的类型。
100 |
101 | 我们建议解除 `withMemoryRebound` 的一些显着限制，并启用重新绑定到更大的类型集，以及从原始内存指针和缓冲区重新绑定。
102 |
103 | **11. Tim Condon** 向我们介绍了 [async/await 和 Vapor 的未来](https://forums.swift.org/t/async-await-and-the-future-of-vapor/52590 "async/await and the future of Vapor.")。
104 |
105 | **12. Drew McCormack** 提出了一项提案，该提案将创建用于[在并发系统中处理共享数据的标准库数据结构](https://forums.swift.org/t/proposal-a-standard-library-type-for-working-with-shared-data-in-a-concurrent-system/52603 "standard library data structures designed for working with shared data in a concurrent system.")。
106 |
107 | 我想在这里提出这样一种类型：分支资源。
108 |
109 | `BranchingResource` 将是一种类型，其携带的有效负载（即资源）具有通用参数。 资源将从单个分支开始，称为“`main`”或“`trunk`”或“`truth`”。 该应用程序可以添加任意数量的辅助命名分支。
110 |
111 | **13. Pavel Yaskevich** 提出了[启用 multi-statement closure parameter/result type 推断](https://forums.swift.org/t/pitch-enable-multi-statement-closure-parameter-result-type-inference/52619 "enable multi-statement closure parameter/result type")的想法。
112 |
113 | 我建议通过从闭包主体中启用参数和结果类型推断来改进多语句闭包的推理行为。
114 |
115 | 这将使开发人员的类型推断不那么令人惊讶，并消除了在闭包中添加多一个表达式或语句可能会导致编译失败的问题。
116 |
117 | ## 推荐博文
118 |
119 | ### iOS 系列
120 |
121 | [百度一面总结（含答案）](https://mp.weixin.qq.com/s/ZprPxK8NbMqpP9flmWRagg)
122 |
123 | [使用 Swift 实现 Promise](https://mp.weixin.qq.com/s/PYzQN5HYXLU1JuXBAZNyhQ)
124 |
125 | 我最近在找如何使用 Swift 实现 `Promise` 的资料，因为没找到好的文章，所以我想自己写一篇。通过本文，我们将实现自己的 `Promise` 类型，以便明了其背后的逻辑。
126 |
127 | [用 Swift 实现轻量的属性监听系统](https://mp.weixin.qq.com/s/8_utYi3y7I3ukh4VpnIM3A)
128 |
129 | 本文的主要目的是解决客户端开发中对“模型的一处修改，UI 要多处更新”的问题。当然，我们要知晓解决方案的细节和思考过程，以及看到其能达到的效果。我们会用到函数式编程的思想，以及伟大的“泛型”。
130 |
131 |
132 | ### SwiftUI 系列
133 |
134 | [用 SwiftUI 实现 3D Scroll 效果](https://mp.weixin.qq.com/s/hfe1m5bNiA0DzdFTEvi9sQ)
135 |
136 | 学完本教程后，你就可以在你的 App 中把这种 `3D` 效果加入任何自定义的 SwiftUI 视图。
137 |
138 | [如何让 SwiftUI 的列表变得更加灵活](https://mp.weixin.qq.com/s/TD0I96HSUoTNmOmfySCtYQ)
139 |
140 | `List` 可能是 `SwiftUI` 附带的内置视图中最常用的一种，它使我们能够在任何 `Apple` 平台上呈现“类似于表格视图”的用户界面。今年，`List` 获得了许多非常重要的升级，使其更加灵活和易于定制。让我们看看都有哪些新功能。
141 |
142 | [使用 SwiftUI 创建万花尺](https://mp.weixin.qq.com/s/snJJi9KYViFErdJAP1HEPQ)
143 |
144 | 为了完成一些真正意义上的绘图工作，我将带您通过创建一个简单的带 SwiftUI 的 `spirograph`。“Spirograph”是一种玩具的商标名称，你把一支铅笔放在一个圆圈里，然后绕着另一个圆圈的圆周旋转，创造出各种几何图案，称为轮盘赌——就像赌场游戏一样。
145 |
146 | ## 关于我们
147 |
148 | 公众号是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。欢迎关注公众号：**Swift社区**，后台点击进群，联系我们获取更多内容。
149 |
150 |
151 |
152 |
153 | 感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。周报仓库：https://github.com/SwiftCommunityRes
154 |
155 | 后续还会翻译大量资料到我们公众号，有感兴趣的朋友，可以加入我们，扫码添加微信
156 |
157 |
158 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_46.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组整理周报的第四十六期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 没有永远的上游，但我们可以永远向上游。**Swift社区**让你如鱼得水，激流勇进！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：卖不动了？iPhone 15 系列跌破 5000 元大关
12 | >
13 | > 提案：Low-Level Atomic Operations 提案通过审查
14 | >
15 | > Swift 论坛：讨论 `1 << x` 类型推断
16 | >
17 | > 推荐博文：Swift 的内购测试
18 |
19 | > **话题讨论：**
20 | >
21 | > 你是否设想过自己35岁之后该做什么工作呢？
22 |
23 | ### 卖不动了？iPhone 15 系列跌破 5000 元大关
24 |
25 | 【环球网科技综合报道】连日来，苹果全线产品在官方旗舰店以及线上平台迎来降价。
26 | 1 月 15 日早间，苹果（中国大陆）官网发布降价信息，1 月 18 日 - 21 日苹果部分产品新春促销，iPhone 15 全系列参与活动，手机产品最高降价 500 元，苹果笔记本电脑产品最高降价 800 元。
27 | 继苹果官网降价后，京东也宣布年货节活动，苹果产品京东自营旗舰店 iPhone 15 系列最高可减 1050 元、iPhone 14 最高可减750 元。其中，iPhone 15 Pro Max 256GB 版到手价 8949 元，iPhone 15 Pro 256GB 版到手价 7949 元，iPhone 15 128GB 版到手价 4949 元，以上机型全部可享限时 12 期免息。此外，iPad 指定产品最高优惠 700 元、 MacBook指定型号最高可优惠 1400 元。
28 |
29 | 
30 |
31 | 不难看出，相比 1 月 15 日苹果官网所公布的新春降价，此次电商平台优惠力度明显更大。业内人士称，产品接连降价，难道苹果卖不动了？
32 | 根据苹果公司 2023 财年财报（截至 2023 年 9 月 30 日），三季度，苹果大中华区营收为 150.84 亿美元，同比下降 2.5%；整体营收为 894.98 亿美元，下降 0.72% ，且除了 iPhone 业务以外的其他所有硬件业务均出现了同比下滑。
33 | 而在不久前，据美国投行杰富瑞（Jefferies）分析师发布的报告，苹果公司 iPhone 在中国市场销量下滑的颓势正在加剧，iPhone 销量在 2024 年第一周就出现了断崖式下跌，较上年同期暴跌 30% 。
34 | 但 Counterpoint Research 方面指出，苹果依然是高端手机市场无可争议的领导者，不过与 2022 年相比，其市场份额确有所下降。2023 年三季度，苹果手机销量同比下滑 10%，市场占有率由 2022 年同期 15.3% 下降至 14.2% 。华为、小米同期市占率分别提升了 3.8 个百分点和 1 个百分点。
35 |
36 | ### StoreKit 和审核指南更新
37 |
38 | 2024 年 1 月 16 日
39 |
40 | 从即日起，根据美国法院近期的一项判决，《App Store 审核指南》第 3.1.1 部分已更新，以推出 StoreKit 购买链接授权 (美国)。该授权适用于在美国店面的 iOS 或 iPadOS App Store 上提供 App 内购买项目的 App，获得授权的开发者可在 App 内包含自己网站的链接，以告知用户还有其他购买数字商品或服务的方式。
41 |
42 | 我们认为，Apple 的 App 内购买项目系统是用户购买数字商品和服务极为安全可靠的方式。因此，对于 App 内的数字商品和服务购买，你仍需使用 App 内购买项目系统。如果你考虑同时使用此授权，请务必了解，在你的网站上购买项目的顾客将无法使用某些 App Store 功能，例如“购买前询问”或“家人共享”。而且，Apple 将无法协助顾客处理退款、购买历史记录、订阅管理以及购买数字商品和服务时遇到的其他问题。你将需要与顾客一起解决此类问题。
43 |
44 | 对于通过 StoreKit 购买链接授权 (美国) 促成的数字购买，Apple 将收取一定的收益抽成。
45 |
46 | ### 将你的 App 提交到 Apple Vision Pro 的 App Store
47 |
48 | 2024 年 1 月 8 日
49 |
50 | Apple Vision Pro 将拥有全新的 App Store，帮助用户发现并下载各款出色的 visionOS App。我们提供了一个新的页面介绍如何准备 App 并将其提交到 App Store，非常适用于已构建了新的 visionOS App 的开发者，以及将向 Apple Vision Pro 用户提供 iPad 或 iPhone App 的开发者。
51 |
52 | ## 提案
53 |
54 | ### 通过的提案
55 |
56 | [SE-0410](https://github.com/apple/swift-evolution/blob/main/proposals/0410-atomics.md "SE-0410") **Low-Level Atomic Operations** 提案通过审查。该提案已在 **四十期周报** 正在审查的提案模块做了详细介绍。
57 |
58 | [SE-0413](https://github.com/apple/swift-evolution/blob/main/proposals/0413-typed-throws.md "SE-0413") **Typed throws** 提案通过审查。该提案已在 **四十二期周报** 正在审查的提案模块做了详细介绍。
59 |
60 | ## Swift论坛
61 |
62 | 1) 提议[字符串插值的默认值](https://forums.swift.org/t/pitch-default-values-for-string-interpolations/69381 "字符串插值的默认值")
63 |
64 | **内容概括**
65 |
66 | 该提案建议向 Swift 添加一项新功能，以解决涉及可选值的字符串插值的挑战。 目前，当在字符串中插入可选值时，开发人员面临警告和提供默认值的选项有限的问题。 所提出的解决方案建议引入新的字符串插值重载，该重载允许开发人员指定默认字符串，而不管可选值的类型如何。
67 |
68 | **介绍**
69 |
70 | Pitch 建议在插入可选值时使用新的默认值字符串插入语法。
71 |
72 | **动机**
73 |
74 | 字符串插值很强大，但在处理可选值时会变得复杂。
75 | 当前的解决方案在处理可选值时涉及繁琐的代码或不需要的输出。
76 |
77 | **例子**
78 |
79 | 演示插入可选字符串和可选整数时的挑战。
80 | 当前的解决方案涉及笨拙的代码或零合并运算符的限制。
81 |
82 | **建议的解决方案**
83 |
84 | 引入新的插值重载，允许将预期默认值指定为字符串，而不管值的类型如何。
85 |
86 | ```Swift
87 | let age: Int? = nil
88 | print("Your age: \(age, default: "missing")")
89 | ```
90 |
91 | **详细设计**
92 |
93 | 这个新的插值重载的实现如下所示：
94 |
95 | ```Swift
96 | extension String.StringInterpolation {
97 | mutating func appendInterpolation(
98 | _ value: T?,
99 | default: @autoclosure () -> String
100 | ) {
101 | self.appendLiteral(value.map(String.init(describing:)) ?? `default`())
102 | }
103 | }
104 | ```
105 |
106 | 2) 讨论[Swift Rational - 用于处理有理数的 Swift 包](https://forums.swift.org/t/swift-rational-swift-package-for-working-with-rational-numbers/69344 "Swift Rational - 用于处理有理数的 Swift 包")
107 |
108 | **内容概括**
109 |
110 | Swift Rational 提供了 RationalModule 模块，用于在 Swift 中处理有理数。
111 |
112 | RationalModule 导出 Rational 结构。 它符合标准 Swift 协议，如 AdditiveArithmetic、Numeric、Hashable、Comparable 等。
113 |
114 | 您可以使用分数初始值设定项创建有理值。
115 |
116 | ```Swift
117 | let half = Rational(2, 4)
118 | print(x.numerator) // 1
119 | print(x.denominator). // 2
120 | ```
121 |
122 | 您还可以使用整数初始值设定项。
123 |
124 | ```Swift
125 | let one = Rational(1)
126 | ```
127 |
128 | 或者只是一个整数文字。
129 |
130 | ```Swift
131 | let two: Rational = 2
132 | ```
133 |
134 | Rational 支持标准算术和比较运算符。
135 |
136 | ```Swift
137 | Rational(1, 2) + Rational(1, 4) // Rational(3, 4)
138 | Rational(1) - Rational(1, 2) // Rational(1, 2)
139 | Rational(2) * Rational(3, 4) // Rational(3, 2)
140 | Rational(1) / Rational(1, 2) // Rational(2, 1)
141 | Rational(1, 2) < Rational(3, 4) // true
142 | ```
143 |
144 | Github库连接：https://github.com/abdel-17/swift-rational
145 |
146 | 3) 讨论[1 << x 类型推断](https://forums.swift.org/t/1-x-type-inference/69417 "1 << x 类型推断")
147 |
148 | **提问**
149 |
150 | 发现了这个区别：
151 |
152 | ```Swift
153 | let x: UInt64 = 1
154 | print(type(of: 1 + x)) // UInt64
155 | print(type(of: 1 << x)) // Int
156 | ```
157 |
158 | 第二个结果是错误还是功能？ 我也希望在那里得到 UInt64 。
159 |
160 | **回答**
161 |
162 | 移位值中的位完全来自左侧，并且移位的限制也来自左侧，因此结果类型始终与左侧匹配。 这使您可以使用 Int8 固定字段来描述 UInt64 值的移位，这完全没问题，因为最大有用移位量为“64”。
163 |
164 | 4) 讨论[类型转换是如何工作的？](https://forums.swift.org/t/how-does-type-casting-work/69350 "类型转换是如何工作的？")
165 |
166 | 类型转换如何，例如 as？ 运算符，实施了吗？
167 | 例如，考虑 eqZero 函数
168 |
169 | ```Swift
170 | func eqZero(_ x: T) -> Bool {
171 | guard let x = x as? Int else { return false }
172 | return x == 0
173 | }
174 | ```
175 |
176 | x 参数是否带有类型标记来检查它是否可以在运行时向下转换？
177 | 如果是这样，如果不使用此类转换操作，编译器是否足以优化掉此类标签？
178 |
179 | **回答**
180 |
181 | 从技术上讲，传入的不是一个框，它“只是”一个指针，类型作为单独的参数传递。 这对于值已经在堆栈或堆上的情况很有帮助。 当您使用 Any 或 any Blah 时，会出现“box”形式，因为这样值必须与其类型保持关联，但对于泛型和某些 Blah 来说，单独传递它们会更灵活，并且可以减少分配流量。 这也意味着当在参数列表中多次使用该类型时，只需传递一次。
182 |
183 | 5) 讨论[~Copyable 和 Completion Handlers](https://forums.swift.org/t/copyable-and-completion-handlers/69383 "~Copyable 和 Completion Handlers")
184 |
185 | 我想编写一些代码，在其中我可以静态地确保将调用完成处理程序。 像这样的东西：
186 |
187 | ```Swift
188 | struct CompletionHandler: ~Copyable {
189 | private let f: (T) -> Void
190 | init(f: consuming @escaping (T) -> Void) { self.f = f }
191 | consuming func callAsFunction(_ t: T) -> Void {
192 | f(t)
193 | }
194 | }
195 | ```
196 |
197 | 基本上，这个想法是，这里的清理需要调用处理程序，因为处理程序的闭包已捕获需要释放或以其他方式解析的资源。
198 | 我希望将这种类型的实例传递给另一个函数，如下所示：
199 |
200 | ```Swift
201 | func invokeHandler(_ completion: consuming CompletionHandler) {
202 | // don't invoke the handler
203 | }
204 | ```
205 |
206 | 将无法编译，因为尚未调用该类型的唯一消耗路径。
207 | 但这段代码看起来不错，我假设 bc 消耗可以简单地取消初始化完成处理程序。 我正在尝试做的事情是否可能或可能已计划但尚未实施？
208 |
209 | **回答**
210 |
211 | 由于提前退出和仿制药等问题，它变得很棘手。 一种思考方式是 ~Ignorable 是与 ~Copyable 类似的条件，但又不同。 其技术术语是“线性类型”或“相关类型”，您可以在此论坛上找到一些先前的讨论。
212 |
213 | @escaping 闭包是可复制类型，并且可复制类型的借用/消耗实际上并不能保证对值的生命周期产生静态影响，因为您始终可以通过复制值来延长生命周期。 当调用者可能拥有对值的唯一剩余引用时，使用消费是一种优化，允许调用者存储参数或将其用作聚合返回值的一部分而不复制它，或者只是提前结束其生命周期 。
214 |
215 | ## 推荐博文
216 |
217 | [Swift 的内购测试](https://swiftwithmajid.com/2024/01/09/storekit-testing-in-swift/ "Swift 的内购测试")
218 |
219 | **摘要：** 这篇博客介绍了在 Swift 中使用 StoreKitTest 框架进行应用内购买测试的方法。作者首先概述了最近 StoreKit 框架的重大变化，强调了新版本充分采用了 Swift 语言的异步和等待特性。
220 |
221 | 随后，博客详细介绍了 `StoreKitTest` 框架，该框架允许我们编写测试用例以验证应用在应用内购买、退款、ask-to-buy 和订阅过期等方面的处理能力。通过示例代码，演示了如何使用 SKTestSession 类型执行购买、管理交易、模拟退款以及测试应用对交易更新的反应。博客还提到了创建 StoreKit 配置文件的必要性。
222 |
223 | [Swift Evolution：阅读提案并从中学习](https://www.avanderlee.com/swift/swift-evolution-proposals/ "Swift Evolution：阅读提案并从中学习")
224 |
225 | **摘要：** 这篇博客介绍了 Swift 编程语言的演进过程，重点关注了通过阅读和学习 Swift Evolution 提案来了解语言变化的方式。作者指出 Swift 的不断演进源于 Swift Evolution 仓库内的公开提案，这些提案是了解最新发展的良好途径。
226 |
227 | 博客解释了 Swift Evolution 的定义和作用，强调了语言开源的特点，任何人都可以通过提出好的想法来影响未来功能和方向。提案经过讨论和批准后成为发布目标，可以在官方 Swift 网站上进行跟踪。作者还简要概述了从提出一个提案到将其纳入 Swift 发布的过程，强调了提案经历多个状态。读者被鼓励查阅 Swift Evolution 过程文档获取最新状态概述。
228 |
229 | [ElasticSearch 与 Swift 集成](https://juejin.cn/post/7326265442837528586/ "ElasticSearch 与 Swift 集成")
230 |
231 | **摘要：** 本篇博客详细介绍了 `Elasticsearch` 与 Swift 的集成，旨在帮助开发者将强大的搜索引擎功能整合到 Swift 应用程序中，提升用户体验。文章首先介绍了 Elasticsearch 和 Swift 的背景，分别强调了 Elasticsearch 作为基于 Lucene 的搜索引擎的特性，以及 Swift 作为苹果主要开发语言的优势。
232 |
233 | 核心概念与联系部分深入解释了集成前需要了解的核心概念，包括 Elasticsearch 的索引、查询、分词、词典等原理，以及 Swift 的类型安全、自动引用计数、高性能等特点。接着，文章详细探讨了集成的操作步骤，包括安装 Elasticsearch 、创建索引、使用 Swift 访问 `Elasticsearch` 、执行搜索查询等步骤。
234 |
235 | ## 话题讨论
236 |
237 | 每个年轻人都会慢慢长大，每个程序员也会逐渐变老，你是否设想过自己 35 岁之后该做什么工作呢？
238 |
239 | 1. 努力成为中高层领导
240 | 2. 继续专研技术成为高级程序员
241 | 3. 成为培训老师
242 | 4. 成为独立开发者带队出来接项目
243 | 5. 创业单干，成就梦想
244 | 6. 出国，国外程序员对年龄要求甚小
245 | 7. 转行跑滴滴，送外卖，做销售。
246 |
247 | 欢迎在文末留言参与讨论。
248 |
249 | ## 关于我们
250 |
251 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
252 |
253 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
254 |
255 |
256 |
257 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
258 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_5.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | Apple 举办了 `Unleashed` 活动发布了新品，借助超强的 `M1 Pro` 或 `M1 Max` 芯片，不管是基于新款的 `MacBook Pro` 开发应用，还是开发 `MacBook Pro` 下的应用，新机都将给我们带来突破性的性能和惊人的电池使用时长。
4 |
5 | 再加上强大的神经引擎，用于增强机器学习和升级的支持 `ProRes` 的媒体引擎，新款 `MacBook Pro` 能让我们的 App 做前所未有的事情。
6 |
7 | > 为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与**周报编辑**，同时邀请赞助商对我们平台赞助支持。
8 |
9 | ## 入门任务
10 | **SR-15312** [Swift-DocC] [添加 “version” 命令到 docc 命令行工具中](https://bugs.swift.org/browse/SR-15312 "Add 'version' command to docc command line tool")
11 |
12 | **SR-15312** [Swift-DocC] [当浏览器 URL 不是小写时，主教程导航下拉菜单无法将当前教程字体加粗](https://bugs.swift.org/browse/SR-15313 "Primary tutorial navigation dropdown fails to bold the current tutorial when browser URL is not lowercased")
13 |
14 | ## 新闻和社区
15 | **Franklin Schrans** 宣布 [Swift-DocC](https://swift.org/blog/swift-docc/ "Swift-DocC is Now Open Source") 将要开源.
16 |
17 | **Marin Todorov** 终于披露了他关于 [`Swift Markdown`](https://github.com/apple/swift-markdown "Swift Markdown") 的工作.
18 |
19 | **Federico Zanetello** 写了一篇[文章](https://www.fivestars.blog/articles/warn_unqualified_access/ "warn_unqualified_access")来说明 `@warn_unqualified_access` 的使用.
20 |
21 | **Dave DeLong** 解释了如何[简化 Swift 中的向后兼容性](https://davedelong.com/blog/2021/10/09/simplifying-backwards-compatibility-in-swift/ "Simplifying Backwards Compatibility in Swift")。
22 |
23 | `Swift-DocC` 的文档现在已经发布在 [Swift.org](https://swift.org/documentation/docc/ "Docc") (使用 [Swift-DocC!](https://forums.swift.org/t/documentation-for-swift-docc-is-now-on-swift-org/52914 "Documentation for Swift-DocC is now on Swift.org")).
24 |
25 | ## 正在审查的提案
26 | **SE-0325** [附加包插件 API](https://github.com/apple/swift-evolution/blob/main/proposals/0325-swiftpm-additional-plugin-apis.md "Additional Package Plugin APIs") 正在审查中。
27 |
28 | **SE-0303** 在 `SwiftPM` 中引入了定义构建工具插件的能力, 允许自定义工具在构建打包时被调用。为了支持该特性， **SE-0303** 引入了最小初始 API，插件能够通过该接口获取那些被唤起构建的 Target 的相关信息。
29 |
30 | 该提案扩展了插件 API 以提供更多上下文，包括更丰富的包图表示。 这是为将来支持新类型的插件做准备。
31 |
32 | ## Swift 论坛
33 |
34 | **1. Nuri Amari** 提出了[改进 ClangImporter](https://forums.swift.org/t/pitch-improved-clangimporter-diagnostics/52687 "Improved ClangImporter Diagnostics") 的建议。
35 |
36 | 提出对 `ClangImporter` 的改进建议，当导入 `C` 或 `Objective-C` 实体发生错误时提供更详细的反馈。 就目前而言，当 `ClangImporter` 无法完全或部分导入实体（函数、类型、宏等）时，出现错误是不会提示的。当前的 Swift 编译错误大部分情况下会提示**从未定义过实体**。
37 |
38 | **2. Frederick Kellison-Linn** 提出了[关键路径到函数转换](https://forums.swift.org/t/pitch-generalize-keypath-to-function-conversions/52681 "Generalize keypath-to-function conversions")的想法。
39 |
40 | 该提案介绍了在允许 `(Root) -> Value` 函数的情况下使用键路径表达式 `\Root.value` 的能力。
41 |
42 | `Swift-evolution` 线程：[关键路径表达式作为函数](https://forums.swift.org/t/key-path-expressions-as-functions/19587 "Key Path Expressions as Functions")
43 |
44 | **3. Patrick Pijnappel** 提出了为 [non-open 类实现详尽模式匹配](https://forums.swift.org/t/pitch-exhaustive-pattern-matching-for-non-open-classes/52718 "Exhaustive pattern matching for non-open classes")的建议。
45 |
46 | 由于现在区分了开放类和非开放类，非开放类层次结构应该能够完全匹配。对于添加新子类，不需要添加任何语法就可以完成。
47 |
48 | **4. Guillaume Lessard** 提出了对[指针可用性](https://forums.swift.org/t/pitch-pointer-usability-improvements/52736 "Pointer Usability Improvements")的改进。
49 |
50 | 该提案为 `UnsafePointer`、`Mutable` 和 `Raw` 引入了一些 quality-of-life 改进。
51 |
52 | 1. 添加 API 获取一个 `UnsafeRawPointer` 实例，这是一个从起点推进到给定对齐的实例
53 | 2. 在给定 `UnsafePointer` 的情况下，添加一个 API 获取指向聚合的存储属性的指针 T
54 | 3. 将`Unsafe[Mutable]Pointer` 未选中的下标重命名为包含 `unchecked` 标签
55 | 4. 添加比较任意两种类型的指针的能力
56 |
57 | **5. Pavel Yaskevich** 提出了改进[相同类型约束语法](https://forums.swift.org/t/pitch-light-weight-same-type-constraint-syntax/52889 "Light-weight same-type constraint syntax")的建议。
58 |
59 | 为了实现改进泛型 UI 的目标，我们提出几项改进措施，为了解决协议和泛型类型之间的语法差距，在**关联类型**和**泛型类型**参数相同类型的约束上，隐藏了一些复杂性（视觉上和认知上）。
60 |
61 | **6. Holly Borla** 开始讨论如何[简化引入泛型参数的学习曲线](https://forums.swift.org/t/discussion-easing-the-learning-curve-for-introducing-generic-parameters/52891 "Easing the learning curve for introducing generic parameters")。
62 |
63 | Swift 的泛型系统具有很强的表达能力，但是要理解具有相关类型的协议、带有 where 子句的泛型签名以及其他泛型特性的完整通用性，是将泛型引入 Swift 项目的一个重大障碍。泛型系统的主要目标是通过改进在 Swift 中编写泛型代码的人体工程学，将具体API抽象为泛型API的学习曲线。本次讨论目的是就实现这一目标的可能方向征求意见，并收集在社区中提出的其他想法。欢迎在文末留言提出问题、评论和想法！
64 |
65 | 本帖中的许多想法都是由 **@Joe_Groff** 在[改进泛型 UI](https://forums.swift.org/t/improving-the-ui-of-generics/22814 "Improving the UI of generics") 中提出的。
66 |
67 | **7. Nate Cook** 提出了一个[用于字符串处理的字符类](https://forums.swift.org/t/pitch-character-classes-for-string-processing/52920 "Character Classes for String Processing")的想法。
68 |
69 | [声明性字符串处理概述](https://forums.swift.org/t/declarative-string-processing-overview/52459 "Declarative String Processing Overview")讲述了正则表达式支持的匹配，但没有关于语法和语义的详细信息，将澄清留给后续介绍。
70 |
71 | [正则表达式的文本](https://forums.swift.org/t/pitch-regular-expression-literals/52820 "Regular Expression Literals")提供了关于正则表达式语法的更多细节，例如分隔符和 `PCRE-syntax` 内部结构，省略了对正则表达式语义的讨论。本帖的目的旨在解决正则表达式语义的目标子集：**字符类的定义**。我们建议直接在现有的 `Character` 和 `Unicode.Scalar` 上和新提出的 API 背景下来处理。
72 |
73 | 正则表达式中的字符类包括元字符，例如匹配数字的 `\d`、匹配空格的 `\s` 和 匹配任何字符的 `.`。单个文字字符也可以被认为是字符类，因为它们至少与自己匹配，并且在不区分大小写的匹配中，与大小写切换的对应字符匹配。因此，将字符类视为正则表达式字面量的任何部分，该部分可以匹配字符串的实际组件。
74 |
75 | ## 推荐博文
76 |
77 | [Swift 5 从零到精通 iOS 开发训练营](https://mp.weixin.qq.com/s/vjC45D5249397bfUCXfhLg)
78 |
79 | 《Swift 5 从零到精通 iOS 开发训练营》是一本从基础到 iOS 项目开发的实战教程，由资深 iOS 开发程序员珲少亲自操刀编撰而成。`文末有送书抽奖，抽奖为 Swift社区 额外福利`
80 |
81 | [iOS UI 自动化测试原理以及在 Trip.com 的应用实践](**https://mp.weixin.qq.com/s/qM4O-wBCZgvn0oFCR7kIbA**)
82 |
83 | 来自携程 IBU 公共无线倪瑶的实战分享： iOS UI 自动化测试实战以及原理总结。
84 |
85 | [一文带你读懂 Swift 社区最新开源的算法库](https://mp.weixin.qq.com/s/7-QlpcfhTaw4D_SmQYbmfA)
86 |
87 | 最近 Swift 社区动作频频，又是登陆 Windows，又是推出底层基础库。现在又推出了 Swift 算法库，现在让我们看看里面到底有什么内容，是否值得现在在生产中应用，面对内容丰富的 `raywenderlich/swift-algorithm-club` 是否有足够的竞争力呢。
88 |
89 | [多角度体会 Swift 方法派发](https://mp.weixin.qq.com/s/aoQuDd58LQRSbJty5Tyjfw)
90 |
91 | 我们知道 Swift 有三种方法派发方式：静态派发（直接派发）、VTable 派发（函数表派发）、消息派发。下面我们分别从 SIL 中间语言，以及汇编的角度体会 Swift 的方法派发方式。
92 |
93 | ## 关于我们
94 |
95 | 公众号是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。欢迎关注公众号：**Swift社区**，后台点击进群，联系我们获取更多内容。
96 |
97 |
98 |
99 |
100 | 感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。周报仓库：https://github.com/SwiftCommunityRes
101 |
102 | 后续还会翻译大量资料到我们公众号，有感兴趣的朋友，可以加入我们，扫码添加微信
103 |
104 |
105 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_56.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十六期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 夜色难免黑凉，前行必有曙光。**Swift社区**不相信运气，但坚信勇气。且与旧事归于尽，明日依旧迎花开！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：苹果暂停高端 Vision 头戴设备研发 计划推出更廉价版
12 | >
13 | > Swift 论坛：讨论 Swiftly 即将推出的增强功能
14 | >
15 | > 推荐博文：Swift 中的仓库设计模式详解
16 | >
17 | > **话题讨论：**
18 | >
19 | > 苹果将新 AI 功能限制在高端设备的策略，这会让你换新的 iPhone 吗？
20 | >
21 | >**上期话题结果**
22 |
23 | 
24 |
25 | 在目前情况下，全国统一高考试卷的实施需要谨慎对待。虽然统一试卷在一定程度上能够提高考试的公平性和质量，但也必须考虑到各地教育发展的不平衡性。
26 |
27 | ## 新闻和社区
28 |
29 | ### 苹果与消费者修改 3500 万美元 iPhone 音响和解协议
30 |
31 | 2024 年 6 月 22 日
32 |
33 | 苹果公司和消费者的律师更新了一项价值 3500 万美元的和解协议，该协议将解决苹果公司销售的 iPhone 7 和 7 Plus 手机音质差、通话能力受损的指控。美国加州北区地方法院于 2023 年 11 月初步批准了该和解协议。消费者称，iphone 的一个缺陷降低了音频质量，使其难以拨打电话或使用 Siri 等功能。(来源：新浪网)
34 |
35 | ### 苹果(AAPL.US)因监管担忧今年不会在欧盟推出 AI 功能
36 |
37 | 2024 年 6 月 22 日
38 |
39 | 
40 |
41 | 苹果( AAPL.US )拒绝向欧盟数亿消费者提供大量 AI 新技术，理由是欧盟监管机构试图控制大型科技公司，这引发了担忧。苹果今年将不会对欧盟用户发布 Apple Intelligence、iPhone Mirroring 和 SharePlay Screen Sharing，因为据称《数字市场法》会迫使苹果降低产品和服务的安全级别。
42 |
43 | 苹果在一份声明中说，“我们担心《数字市场法》对互操作性要求可能会迫使我们以削弱用户隐私和数据安全的方式损害产品的完整性”。
44 |
45 | 《数字市场法》对被归为“看门人公司”的互联网巨头企业提出一系列规范性要求，包括不得滥用市场支配地位打压或并购竞争对手、不得未经用户允许强行推送广告或安装软件，不得将采集的用户数据移作他用等等。违者将被处以相当于该企业年营业额 10% 的高额罚款。作为规定的一部分，欧盟指定 6 家最大的科技公司为“看门人”——需要更严格审查的强大平台。除苹果外，这份名单还包括微软( MSFT.US )、谷歌母公司 Alphabet( GOOGL.US )和 Facebook 所有者 Meta Platforms(META.US)。
46 |
47 | 欧盟委员会在回应苹果的计划时表示:“只要遵守我们旨在确保公平竞争的规定，我们欢迎守门人在欧洲提供服务。”
48 |
49 | 苹果的 AI 技术“苹果智能( Apple Intelligence )”是其最近全球开发者大会( WWDC )演讲的亮点，该演讲还包括对苹果操作系统的更新。该技术将有助于总结文本、创建原始图像，并在用户需要时检索最相关的数据。这一举措还包括升级后的 Siri，这是苹果曾经开创性的数字语音助理。这些新功能在最近几周帮助推动了苹果股价的上涨。自 6 月 10 日的 WWDC 发布会以来，苹果股价已经上涨了约 9%，使该公司的估值超过 3.2 万亿美元。
50 |
51 | 苹果决定停止在欧盟的推广 AI 技术服务，这意味着欧盟所有 27 个国家的消费者，包括法国、德国、西班牙和意大利等国，目前将无法获得该公司雄心勃勃的新人工智能技术。这款软件将于今年秋天在其他地方推出，但只适用于苹果的一小部分设备，而且只支持美式英语。目前尚不清楚这些功能可能如何违反《数字市场法》，但苹果拒绝提供该技术可能会激怒该地区的消费者，他们可能会向监管机构施加压力。
52 |
53 | 苹果高管已经在大型科技公司的市场垄断问题上与欧盟发生争执。苹果最早将于周一收到欧盟监管机构根据《数字市场法》发出的正式警告，原因是苹果涉嫌阻止应用程序引导用户在网络上进行更便宜的订阅交易——根据传统的反垄断法，苹果今年早些时候已经被布鲁塞尔监管机构处以 18 亿欧元( 19 亿美元)的罚款。(来源：智通财经网)
54 |
55 | ### 苹果暂停高端 Vision 头戴设备研发 计划推出更廉价版
56 |
57 | 2024 年 6 月 19 日
58 |
59 | 据《信息报》周二报道，援引自一家为苹果 VisionPro 提供关键部件的制造商员工，苹果公司目前已经暂停了对下一代高端 Vision 头戴设备的研发。此消息一出，立即在科技界引发了广泛关注。
60 |
61 | 报道中提到，有供应链及耳机制造的相关人士透露，这家知名的 iPhone 制造商目前正集中精力，计划在明年年底之前推出一款价格更为亲民、功能较为简化的 Vision 产品。面对路透社的评论请求，苹果公司尚未立即作出回应。
62 |
63 | 业内分析认为，这一策略调整可能与市场需求的变化有关。苹果原计划在包括中国和日本在内的八个新国家推广其售价为 3500 美元的 VisionPro，以期提振销量。然而，在产品发布初期的热潮过后，该设备面临着需求放缓的挑战。
64 |
65 | 本月早些时候，在苹果的年度开发者大会上，公司揭开了其人工智能战略的神秘面纱，同时宣布了与 ChatGPT 的制造商 OpenAI 的合作关系。这一消息发布后，苹果股价得到了显著提升，今年迄今为止已上涨超过 11%。这一涨幅是在年初中国 iPhone 需求疲软，苹果股价一度落后于其他大型科技公司的情况下实现的。
66 |
67 | 报道还提到，苹果原本打算效仿 iPhone 的产品线，将 Vision 产品分为标准版和 Pro 版两种型号。但现在，随着研发重点的转移，这一计划可能会有所调整。
68 |
69 | 据悉，苹果在过去的一年中逐渐降低了 VisionPro 继任产品的开发优先级。公司内部资源分配的变化显示，开发下一代车型的员工数量在减少，而公司更多地专注于降低第一代车型的零部件成本，以提高产品的市场竞争力。(来源：环球网)
70 |
71 | ## Swift论坛
72 |
73 | 1) 宣布[Swift 项目的新 GitHub 组织](https://forums.swift.org/t/new-github-organization-for-the-swift-project/72336 "Swift 项目的新 GitHub 组织")
74 |
75 | **内容概括**
76 |
77 | Swift 编程语言正在迁移到一个专门的 GitHub 组织（GitHub.com/swiftlang）。这一迁移反映了 Swift 社区的成长和成熟，并强调了 Swift 在 Apple 生态系统之外的多样性。新的 GitHub 组织将为协作和创新创造更有利的环境，使 Swift 能够扩展到更多平台和用例。
78 |
79 | 迁移将分阶段进行，初始范围包括 Swift 项目的基础元素，如编译器、核心工具、标准库、核心 API、示例、Swift.org 网站以及官方客户端和驱动程序等。
80 |
81 | 迁移过程将解决几个关键的治理方面，包括新项目整合方法、扩大贡献者基础、明确提交者角色，以及扩展持续集成支持。
82 | 这是一个社区范围的努力，由核心团队、贡献者体验工作组、Swift 服务器工作组和网站工作组等多个群体共同推动。迁移将逐步进行，保持完全透明。
83 |
84 | 作为第一步，swift-evolution 仓库将于今天迁移，其他仓库将在接下来的几周内陆续转移。核心团队对过去十年来为 Swift 梦想做出贡献的每个人表示深深的感谢，并期待 Swift 的下一个篇章。
85 |
86 | 2) 讨论[[已接受] Swift 测试的新方向](https://forums.swift.org/t/accepted-a-new-direction-for-testing-in-swift/72309 "[已接受] Swift 测试的新方向")
87 |
88 | **内容概括**
89 |
90 | 将成立 Swift 测试工作组，隶属于生态系统指导小组。
91 | 该愿景是 swift-testing 项目的延续，旨在改进 Swift 的测试 API 和工具。
92 |
93 | 语言指导小组和平台指导小组已审核并接受了这一愿景。
94 |
95 | 该文档强调了测试的目标和基本设计方法，具体设计将由社区讨论和审核。
96 |
97 | 然而，有评论指出：
98 |
99 | 1. 这些变化主要是表面的，focusí 于改善易用性和表达能力。
100 | 2. 缺乏解决开发者在测试中遇到的最大问题的雄心，例如没有涉及模拟（mocking）。
101 | 3. 模拟是开发者最 struggle 的部分，与 Swift 的严格类型系统相矛盾。
102 | 4. 需要更多、更大的创意来真正实现 Swift 测试的"新方向"。
103 |
104 | 总的来说，这个愿景虽然有所进步，但可能不足以称为测试的"新方向"，还需要更多实质性的改进。
105 |
106 | 3) 讨论[Swiftly 即将推出的增强功能](https://forums.swift.org/t/upcoming-enhancements-to-swiftly/72361 "Swiftly 即将推出的增强功能")
107 |
108 | **内容概括**
109 |
110 | Swiftly 即将推出的增强功能
111 |
112 | Swiftly 是一个命令行工具，帮助用户开始使用 Swift 工具链并在多个版本之间轻松切换。以下是计划中的主要改进:
113 |
114 | 1. macOS 支持：扩展到 macOS 平台。
115 | 2. 命令代理：允许为不同项目指定特定工具链版本。
116 | 3. 迁移到纯 Swift：将安装脚本逻辑移至 Swiftly 本身。
117 | 4. 移除 GitHub API 依赖：改用 swift.org 获取元数据和更新。
118 | 5. 新功能：
119 | - 查询可用工具链
120 | - 设置项目默认版本
121 | - 改进安装体验
122 |
123 | 这些改进旨在使 Swiftly 成为 Swift 的默认安装体验，提高易用性和灵活性。
124 |
125 | 对于 CI 系统，将考虑提供迁移指南。系统级包管理器仍是最无缝的安装方式，但 Swiftly 提供了更灵活的用户级管理。
126 |
127 | 为改善用户体验，计划调整系统依赖项安装流程，提高透明度并保持用户级工具的心智模型。对于 CI 环境，可能会添加检测 root 用户并自动安装依赖的功能。
128 |
129 | 总体目标是让 Swift 开发更accessible，并为新手提供更好的体验。
130 |
131 | 4) 讨论[在某些情况下，“包”访问级别可以是隐式的吗？](https://forums.swift.org/t/can-the-package-access-level-be-implicit-in-certain-contexts/72326 "在某些情况下，“包”访问级别可以是隐式的吗？")
132 |
133 | **内容概括**
134 |
135 | 讨论涉及 Swift 编程语言中 `package` 访问级别的隐式使用。主要问题是：为什么包类型的成员声明不能默认为 package 访问级别？
136 |
137 | 提议的优点：
138 |
139 | 1. 减少代码中显式 `package` 关键字的使用，可能减少约85%。
140 | 2. 如果类型已标记为 package，其成员通常也需要相同级别的可见性。
141 |
142 | 反对意见：
143 |
144 | 1. 可能会降低代码的可读性，使读者更难理解代码。
145 | 2. 可能会影响本地推理能力。
146 |
147 | 讨论还涉及了代码读者如何查找成员引用的问题。对于 public、private 和 fileprivate 成员，查找方法明确。而对于 internal、package 或无显式修饰符的成员，都需要使用全局搜索。
148 |
149 | 提议者认为，在大多数成员都是 package 可见性的情况下，显式的 package 修饰符可能成为视觉干扰。但如果大多数成员是 internal 的，则当前做法更好。
150 |
151 | 最后，讨论指出，即使采用提议的更改，读者也可以通过一次"跳转到定义"操作来确定类型的访问级别。
152 |
153 | 总的来说，这个讨论权衡了代码简洁性和可读性之间的关系，以及对代码作者和读者的影响。
154 |
155 | 5) 讨论[在 switch case 中绑定枚举](https://forums.swift.org/t/binding-enums-in-a-switch-case/72324 "在 switch case 中绑定枚举")
156 |
157 | **内容概括**
158 |
159 | 这个问题讨论了在 Swift 中如何在 switch 语句中绑定枚举值。作者提出了两种方法：
160 |
161 | 1. 使用 if let 进行可选绑定，然后在 switch 语句中匹配枚举值。这种方法是有效的。
162 | 2. 作者希望在 switch 语句中直接处理可选的枚举值，并在每个 case 中绑定非空值。这种语法在 Swift 中是无效的，但作者想知道是否有类似的方法可以实现。
163 |
164 | 作者强调他们主要出于学术原因对这个问题感兴趣，并且关注的是如何在 case 语句内引用枚举实例，而不是具体的处理逻辑。
165 | 这个问题探讨了 Swift 语言中枚举处理和模式匹配的高级用法，反映了对语言特性和语法糖的深入思考。
166 |
167 | 6) 讨论[分布式、分布式集群模块的初学者建议](https://forums.swift.org/t/beginner-advice-for-distributed-distributedcluster-modules/72391 "分布式、分布式集群模块的初学者建议")
168 |
169 | **内容概括**
170 |
171 | 主要讨论了分布式系统中的 Distributed 和 DistributedCluster 模块的使用建议，特别是针对初学者。作者正在尝试解决 Fly.io的Gossip Glomers 挑战中的"高效广播"问题，希望使用这些模块来实现节点间的通信和消息传播。
172 |
173 | 主要内容包括:
174 |
175 | 1. 作者介绍了他在 Elixir/Erlang 生态系统中的分布式系统背景。
176 | 2. 解释了"高效广播"挑战的要求: 25 个程序实例需要形成集群并进行消息广播。
177 | 3. 询问是否有现成的模块可以实现集群、节点发现和通信功能。
178 | 4. 讨论了 Swift 的 ClusterSystem 与 Erlang 节点系统的异同:
179 | - 两者都是基于 TCP 端口的对等节点系统
180 | - Erlang 有额外的守护进程简化了本地节点发现
181 | - Swift 目前需要手动编写节点加入代码，但后续可能会改进
182 | 5. 提供了在 Swift 中启动多个集群节点的代码示例。
183 | 6. 建议改进文档，以便更好地解释节点加入过程和集群形成。
184 | 7. 提出了添加类似 Erlang 的辅助守护进程的想法，以简化 Swift 中的集群配置过程。
185 |
186 | 文章强调了改进文档和用户体验的重要性，以使 Swift 的分布式系统开发对初学者更加友好。
187 |
188 | 6) 讨论[为什么assumeIsolated()现在需要T:Sendable？](https://forums.swift.org/t/why-does-assumeisolated-now-require-t-sendable/72344 "为什么assumeIsolated()现在需要T:Sendable？")
189 |
190 | **内容概括**
191 |
192 | 这段讨论涉及 Swift 语言中的区域隔离（Region-Based Isolation， RBI）和并发安全性。主要观点包括：
193 |
194 | 1. Swift 使用"并发域"而非线程作为并发安全的基础，这可能是一个优势。
195 | 2. RBI 允许在独立区域间传输非 Sendable 值，这引入了新的能力和复杂性。
196 | 3. 有人表示，RBI 的引入使 Swift 并发的安全性变得更加难以理解。
197 | 4. 每个新版本的 Swift 编译器都可能将之前认为安全的操作标记为不安全，这增加了开发者的困惑。
198 |
199 | 这段讨论反映了 Swift 并发模型正在不断演进，同时也带来了一些挑战和争议。
200 |
201 | ## 推荐博文
202 |
203 | [swift 使用 swift-protobuf 协议通讯，使用指北](https://juejin.cn/post/7381826917086232614/ "swift 使用 swift-protobuf 协议通讯，使用指北")
204 |
205 | **摘要：** 文章全面介绍了如何在 Swift 中利用 Swift-protobuf 进行高效的协议通信。作者解释了 Protocol Buffers 的优势，如高效性、简洁性和版本兼容性，以及适用场景。介绍了如何安装 Swift-protobuf 编译器，并通过示例展示了如何编译 .proto 文件生成 Swift 代码。随后，文章详细介绍了如何将生成的 Swift 代码集成到项目中，确保项目能够顺利使用 Swift-protobuf。此外，文章还探讨了常见问题的解决方法，特别是关于模块引用错误的处理。
206 |
207 | 在文章的最后作者还通过一个简单的 SwiftUI 示例演示了如何创建、序列化和反序列化协议消息对象，帮助读者理解实际应用中的操作流程。这篇文章结构清晰，内容详尽，为想要在 Swift 应用中应用 Protocol Buffers 的开发者提供了全面的指导和实用技巧。
208 |
209 | [Swift 中的仓库设计模式详解](https://www.avanderlee.com/swift/repository-design-pattern/ "Swift 中的仓库设计模式详解")
210 |
211 | **摘要：** 这篇博客详细介绍了如何使用仓库（Repository）设计模式在Swift应用中管理数据访问逻辑。文章从定义仓库接口开始，使用 Swift 的协议（protocol）来描述数据操作方法，例如创建、删除和查找用户。接着演示了如何创建多个仓库实现，包括基于内存和基于 UserDefaults 的实现，这些实现隐藏了具体数据存储的细节。
212 |
213 | 最后，文章展示了如何在应用中使用 ViewModel 来操作数据，通过依赖注入不同的仓库实现，实现了数据访问逻辑的灵活切换。通过仓库设计模式，开发者能够更好地组织和测试应用的数据访问层，提升代码的灵活性和可维护性。
214 |
215 | [Swift中的扩展：以及何时使用它们](https://www.avanderlee.com/swift/extensions/ "Swift中的扩展：以及何时使用它们")
216 |
217 | **摘要：** 这篇文章介绍了如何使用 Swift 中的扩展（Extensions），以扩展已有的类、结构体、枚举或协议，增加新功能。无论是自定义类型还是框架中的现有类型，扩展都可以创建自定义访问器，提升与类型的互动体验。文章解释了扩展的基本概念及其在所谓的逆向建模中的应用，让你能在无法访问源代码的情况下，仍能为类型添加自定义功能层。通过示例展示了如何在不同情境下使用扩展，包括为类型添加新属性、实现协议及提供默认行为。总体来说，本文帮助开发者掌握使用 Swift 扩展的重要技能，从而优化代码结构和提高可重用性。
218 |
219 | ## 话题讨论
220 |
221 | 苹果将新 AI 功能限制在高端设备的策略，这会让你换新的 iPhone 吗？
222 |
223 | 1. 会的。AI 功能需要大量计算能力，而旧设备可能难以顺利提供。
224 | 2. 不会。这是推动新硬件销售的理由，再多的RAM也跟不上模型的发展速度。
225 | 3. 中立。我计划至少再使用我的 iPhone 几年，苹果智能不是升级的理由。
226 |
227 | 欢迎在文末留言参与讨论。
228 |
229 |
230 | ## 关于我们
231 |
232 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
233 |
234 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
235 |
236 |
237 |
238 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
239 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_6.md:
--------------------------------------------------------------------------------
1 |
2 | ## 前言
3 |
4 | 译者言：周日立冬，北方多地迎来 2021 年的第一场雪，上海也降下大雨，此时你所在的城市降温了吗？记得添衣保暖，避免感冒生病影响工作和生活。
5 |
6 | [Xcode 13.2 Beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift) 版已具备并发支持，该特性将有助于解决很多 Swift 开发者的某些痛点。或许 Swift 内置的并发系统最重要的好处是，它允许以更简单的方式，并行执行多异步任务。可以想像，通过增加执行任务的速度这将节省我们更多时间。
7 |
8 | [Kristaps Grinbergs](https://twitter.com/fassko) Swift 周报负责人在本期周报中公开自己将不再领导 Swift 周报项目，原文如下：
9 |
10 | 我非常高兴地编写这么优秀并且已经运营了三年的 Swift 新闻周报。我遇到了很多了不起的人，并且感谢你们所有人，我已经收获了很多！ 这是为什么打出下面这句话，让我感慨万千的原因。第 200 期周报将是我运营的最后一期。我已经决定不再领导这个项目，并且怀着愉悦的兴奋，我正在寻找愿意继续管理 Swift 周报的人。
11 |
12 | > 为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与**周报编辑**，同时邀请赞助商对我们平台赞助支持。
13 |
14 | ## 入门任务
15 | **SR-15408** [Swift-DocC] [用含有空格的回调显示名称构建文档会产生一篇无法阅读的文章](https://bugs.swift.org/browse/SR-15408 "Building documentation with a fallback display name that includes a space produces a broken-looking article")
16 |
17 | **译者注：** 如果将带有空格的回调显示名称（如 --fallback-display-name "My Display Name"）以及有效的符号图传递给 DocC，DocC 会生成一篇以“我的显示名称”作为 H1 的文章标题并将其组织在顶级框架页面上的“文章”主题组下。
18 |
19 | ## 新闻和社区
20 |
21 | 新的 [Xcode 13.2 Beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift) 增加了对 macOS 10.15、iOS 13、tvOS 13 和 watchOS 6 或更高版本的 Swift 并发支持。 这种支持包括`async/await`、[actor](https://developer.apple.com/documentation/swift/actor)、全局 `actor`，结构化的并发及其任务 API。
22 |
23 | **Tim Condon** 发布了 [Vapor](https://forums.swift.org/t/async-await-has-arrived-in-vapor/53077 "Async/await has arrived in Vapor") 已经支持 `async/await`。
24 |
25 | **Konrad ktoso Malawski** 写了一篇介绍 [Swift Distributed Actors](https://www.swift.org/blog/distributed-actors/ "Introducing Swift Distributed Actors") 的文章。
26 |
27 | **Marc Aupont** 将加入 Diversity in Swift 工作组。
28 |
29 | Swift 下载链接已移至新位置以提供更快的下载速度！ 工具链将托管在 [download.swift.org](https://www.swift.org/download/)，它将使用与当前 URL 类似的模式。 要使用新 URL，请将 **swift.org/builds/** 替换为 **download.swift.org/**。 从 2021 年 10 月 26 日开始，**swift.org/builds** URL 已重定向到新的子域。
30 |
31 | **Sarun Wongpatcharapakorn** 写了一篇博文解释 Swift 中的 [KeyPath](https://sarunw.com/posts/what-is-keypath-in-swift/ "What is a KeyPath in Swift")。
32 |
33 | ## Commits 和 pull requests
34 |
35 | **Erik Eckstein** 合并了一个 `pull request`，该请求[实现了性能注释的原型](https://github.com/apple/swift/pull/39902 "First prototype of Performance Annotations")，如 Swift 中的 `@_noLocks` 和 `@_noAllocation`。
36 |
37 | **Slava Pestov** 合并了一个 `pull request`，该请求[改进了对“身份一致性”的处理 [P].[P] => [P]](https://github.com/apple/swift/pull/39918 "RequirementMachine: Improved handling of identity conformances")。
38 |
39 | **John McCall** 合并了一个 `pull request`，该请求[修复了高度对齐的结果类型的未来片段的对齐方式](https://github.com/apple/swift/pull/39829 "Fix the alignment of future fragments for highly-aligned result types")
40 |
41 |
42 | ## 同意的提案
43 |
44 | **SE-0325** [附加包插件 API](https://forums.swift.org/t/accepted-with-modifications-se-0325-additional-package-plugin-apis/53086 "[Accepted with Modifications] SE-0325: Additional Package Plugin APIs") 提案已被修改并同意。
45 |
46 |
47 | ## 正在审查的提案
48 |
49 | **SE-0326**: [多语句闭包参数/结果类型推断](https://forums.swift.org/t/se-0326-multi-statement-closure-parameter-result-type-inference/52964 "Multi-statement closure parameter/result type inference")正在审查中.
50 |
51 | **Kristaps Grinbergs** 建议通过启用闭包体的参数和结果类型推断，来改进多语句闭包推断行为。 这将令类型推断更符合开发者的预期，并且移除现存的行为壁垒，即向闭包添加一个表达式或语句会导致编译失败的结果。
52 |
53 | **SE-0327**: [On Actors and Initialization](https://forums.swift.org/t/se-0327-on-actors-and-initialization/53053 "On Actors and Initialization")正在审查中。
54 |
55 | **Actors** 是 Swift 中相对较新的名义类型，为其可变态提供了数据竞争安全性。数据保护是通过将每个 `actor` 实例可变状态一次最多隔离一个任务来实现的。引入 `actor`（[SE-0306](https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md "Actors")）的提案非常庞大和详细，但忽略了创建和销毁 `actor` 隔离状态的一些细微之处。 该提案旨在支持一个 `actor` 的定义，为了弄清一个 `actor` 实例的数据隔离何时开始和结束，以及在一个 `actor` 的 `init` 和 `deinit` 函数声明中能够做什么。
56 |
57 | **SE-0328**：[Structural opaque result](https://forums.swift.org/t/se-0328-structural-opaque-result-types/53248 "SE-0328: Structural opaque result types") 类型正在审查中。
58 |
59 | **Opaque** 结果类型可以用作函数的结果类型、变量的类型或者下标的结果类型。在所有情况下， **Opaque** 结果类型必须是整个类型。该提案建议解除该限制，并且在“结构性”的位置中允许使用 **Opaque** 结果类型。
60 |
61 | ## Swift 论坛
62 |
63 | ### I
64 |
65 | 一个来自 **@justkwin** 关于 `Foundation` 如何使用 `URL` 结束来表示 `file.paths` 的小历史[教训](https://forums.swift.org/t/get-folders-number-of-elements/ "Get Folder’s Number of Elements")。
66 |
67 | ### II
68 |
69 | **Anders Bertelrud** 提出了添加[包管理器命令插件的提案](https://forums.swift.org/t/pitch-package-manager-command-plugins/53172 "[Pitch] Package Manager Command Plugins")。
70 |
71 | **SE-0303** 引入了第一种 SwiftPM 插件，专注于使用自定义构建工具调用扩展构建系统的能力（特别是为了生成源代码）。 那些插件一直计划成为第一种被 SwiftPM 支持的插件。
72 |
73 | **Kristaps Grinbergs** 想提出一个提案草案，为 SwiftPM 添加另一种更通用目的的“命令插件”。 这些类型的插件可以由用户直接调用，用于源代码格式化、文档生成、测试报告生成等。命令插件不一定与构建系统有任何关系。
74 |
75 | 这些自定义命令插件一个重要的方面是它们可以要求插件主机（SwiftPM 或支持包的 IDE）按需生成专门的信息，或着初始化构建或测试运行。 这是提案草案中最需要仔细审查的部分。 在使 API 足够丰富以令其尽可能有用，同时也使其足够通用以不仅在 SwiftPM 中而且 IDE 中支持 Swift 包，这里有一个相悖的因素。
76 |
77 | ### III
78 |
79 | **Guillaume Lessard** 提出了一项提案，该提案将实现[指针族初始化改进](https://forums.swift.org/t/pitch-pointer-family-initialization-improvements/53168 "[Pitch] Pointer family initialization improvements")。
80 |
81 | `UnsafeMutablePointer` 系列中的类型通常需要手动管理内存分配，包括对其初始化状态的管理。 涉及的状态是在分配后:
82 |
83 | 1. 未绑定和未初始化时（当在 `UnsafeMutableRawPointer.allocate()` 返回）
84 | 2. 绑定到一个类型，并且未初始化（从 `UnsafeMutablePointer.allocate()` 返回）
85 | 3. 绑定到一个类型，并且初始化
86 |
87 | 无论何时它未曾被初始化，内存都能够安全地销毁。
88 |
89 | 不幸的是，不是每一个 `UnsafeMutablePointer` 系列中的类型有这个必要功能，以用于全面管理它内存初始化的状态。 我们打算在本提案中解决这个问题，并提供在各种更广泛的情况下管理初始化状态的功能。
90 |
91 | ### IV
92 |
93 | **Kelvin Ma** 展开了一个关于 `AsyncStream` 构造函数的[讨论](https://forums.swift.org/t/asyncstream-constructor-which-also-returns-its-continuation/53251 "AsyncStream constructor which also returns its Continuation")，该构造函数也返回其 `Continuation`。
94 |
95 | 有没有什么方法我们可以向 `AsyncStream` 添加一个 API，它直接返回 `Continuation`，从而我们就不必把它的闭包“调来调去”？
96 |
97 | 一般来说，我也觉得 `AsyncStream` 真的很难使用，因为迭代在创建了 `AsyncStream` 的同一个任务中发生，甚至是没有并发迭代时曾出现。 这使“订阅” `actor` 对象生成的事件变得困难，即使订阅方法被标记为 `nonisolated`。
98 |
99 | ### V
100 |
101 | **Adam Fowler** 积极将 `MQTTNIO` 库[加入 SSWG 包列表中](https://forums.swift.org/t/mqttnio/53238 "Mqttnio").
102 |
103 | MQTT 是一种通常用于与 IoT（物联网）设备进行通信的消息传递协议。 它是一种轻量级的发布/订阅消息传输，旨在具有较小的代码占用空间和网络带宽。
104 |
105 | ### VI
106 |
107 | **Cory Benfield** 向我们[更新了](https://forums.swift.org/t/swiftnio-swift-version-support/53232 "SwiftNIO Swift version support")关于 `SwiftNIO Swift` 版本支持。
108 |
109 | SwiftNIO 团队已将其作为我们工作流程的主要支柱，以尝试在相当长的时间内支持 Swift 版本。大多数用户没有利用这一点，更愿意继续使用最新版本的 Swift，但我们认为重要的是你要有信心，新编写的应用程序将在未来获得一些有意义的支持。
110 |
111 | ### VII
112 |
113 | **Victoria Mitchell** [写了一篇](https://forums.swift.org/t/extending-swift-docc-to-support-objective-c-documentation/53243 "Extending Swift-DocC to support Objective-C documentation")关于扩展 `Swift-DocC` 以支持 `Objective-C` 的文档。
114 |
115 | `DocC` 的架构目前仅支持 `Swift` 一个语言的渲染符号文档。然而，有些跨语言项目可以从将多个“语言变体”收集到同一组文档中受益，例如可以被 `Swift` 中调用的 `Objective-C` API，反之亦然。
116 |
117 | ## 关于我们
118 |
119 | 公众号是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。欢迎关注公众号：**Swift社区**，后台点击进群，联系我们获取更多内容。
120 |
121 |
122 |
123 |
124 | 感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。周报仓库：https://github.com/SwiftCommunityRes
125 |
126 | 后续还会翻译大量资料到我们公众号，有感兴趣的朋友，可以加入我们。扫码添加微信，拉你进群交流
127 |
128 |
129 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_68.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：消息称苹果与腾讯、字节跳动谈判，希望在中国推出 AI 功能
12 | >
13 | > 提案：Package 特征提案通过审查
14 | >
15 | > Swift 论坛：讨论 LSP 与 CMake 和 nightly 工具链集成
16 | >
17 | > 推荐博文：SwiftUI 中 `UIGestureRecognizerRepresentable` 协议使用
18 | >
19 | > **话题讨论：**
20 | >
21 | > 冬天你多久洗一次澡？
22 | >
23 | >**上期话题结果**
24 |
25 | 
26 |
27 | 超越一定程度之后，停止或者慢速发展是不是依旧是超越态势？
28 |
29 | ## 新闻和社区
30 |
31 | ### 消息称苹果已成全球VR/MR头显市场第三大玩家 但Vision Pro销量不及预期
32 |
33 | 2024 年 12 月 20 日
34 |
35 | 据外媒报道，苹果公司在去年 6 月 5 日的全球开发者大会上推出的头显产品 Vision Pro，已在太平洋时间今年 1 月 19 日凌晨 5 点，开始在美国市场接受预订，并在 2 月 2 日正式上市，苹果也就此正式切入了 VR/MR 头显市场，在 6 月份开始推向国际市场，开始在更多国家销售。
36 |
37 | 
38 |
39 | 不过，对于苹果寄予厚望的 Vision Pro，本月早些时候有报道称销量并不乐观，自 2 月份开始上市以来还不到 50 万台，也有外媒提到在前三季度销售了约 37 万台，预计在四季度将再销售 5 万台，全年的销量距 50 万台也会有差距。
40 |
41 | 虽然苹果 Vision Pro 今年的销量看起来并不乐观，但从市场研究机构最新发布的报告来看，苹果还是凭借这一款全新的产品，成为了全球 VR/MR 头显市场第三大玩家。
42 |
43 | 市场研究机构在报告中表示，今年全球 VR/MR 头显的出货量预计将接近 960 万台，同比增长 8.8%。
44 |
45 | 具体到厂商，市场研究机构的报告是显示 Meta 将是销量最高的厂商，在出货量中所占的比例将达到 73%，远高于其他厂商；索尼则是出货量第 2 高的厂商，所占的份额为 9%；苹果 Vision Pro 以 5% 的份额排在第 3。
46 |
47 | 市场研究机构在报告中也提到，Vision Pro 销量要低于苹果的预期，这主要是因为高昂的售价和目前有限的应用资源。（来源：TechWeb）
48 |
49 | ### iPhone 16印尼销售禁令有望解除 消息称印尼高层已认可苹果投资承诺
50 |
51 | 2024 年 12 月 20 日
52 |
53 | 据外媒报道，在苹果公司两度提高投资承诺，由最初的 1000 万美元增至 10 亿美元后，iPhone 16 系列在印尼的销售禁令，终于迎来了将解除的曙光，有消息称他们的投资承诺已经得到了印尼方面的认可。
54 |
55 | 
56 |
57 | 外媒援引知情人士的透露报道称，印尼高层在周末已经得到了相关的简报，支持批准苹果的提议，不过目前还不清楚印尼方面会在何时解除 iPhone 16 的销售禁令。
58 |
59 | 此外，外媒在报道中还提到，虽然印尼高层已经认可了苹果 10 亿美元的投资承诺，但他们也在寻求苹果公司未来更多的投资。
60 |
61 | 就外媒的报道来看，苹果方面承诺的 10 亿美元投资，主要用在三个方面，其一是在巴淡岛建设一座 AirTag 工厂，其二是在万隆建设一座为其他产品生产零部件的工厂，第三是开发者学院。
62 |
63 | 由于苹果目前的硬件产品，无论是关键零部件还是最终的成品组装，都是外包代工商，因而他们计划在印尼建设的两座工厂，是由供应商建设。
64 |
65 | 对于计划建设的 AirTag 工厂，外媒在报道中提到初期就将有约 1000 名员工，最终的产量，将占到 AirTag 全球产量的 20%。
66 |
67 | 苹果 iPhone 16 在印尼被禁售，与零部件 40% 的本土化率及投资承诺未实现有关，苹果此前承诺投资 1.096 亿美元，只完成了 9453 万美元，印尼方面在 10 月 11 日就向苹果发出了警告，在 10 月 28 日发出了针对 iPhone 16 的销售禁令，禁止在当地销售。
68 |
69 | 但由于印尼是全球重要的智能手机市场之一，有报道称人口 2.8 亿的印尼，目前在使用的智能手机约有 3.54 亿部，有可观的用户群体，对苹果来说也是重要的市场，秋季新推出的 iPhone 16 不能销售，势必就会影响到整体的销量，并影响他们的业绩，因而苹果也在尝试通过投资承诺，来解除 iPhone 16 在印尼的销售禁令。
70 |
71 | 就外媒此前的报道来看，在印尼发出销售禁令之后不久，苹果就在尝试通过投资解除销售禁令，在 11 月初承诺投资 1000 万美元，11 月下旬提升至 1 亿美元，但仍未得到认可，印尼方面希望更大的投资，随后就出现了苹果承诺投资 10 亿美元的消息。（来源：TechWeb）
72 |
73 | ### 消息称苹果与腾讯、字节跳动谈判，希望在中国推出 AI 功能
74 |
75 | 2024 年 12 月 19 日
76 |
77 | 据路透社报道，三位知情人士称，苹果公司正在与腾讯、字节跳动谈判，希望将这两家公司的人工智能 (AI) 模型整合到在中国市场销售的 iPhone 中。
78 |
79 | 作为 AI 系统 Apple Intelligence 的一部分，苹果从本月开始在其 iPhone 中整合 ChatGPT 聊天机器人。但是在中国市场，苹果的 AI 功能需要与本土公司合作。
80 |
81 | 知情人士称，苹果与腾讯、字节跳动的谈判涉及使用后两家公司的 AI 模型，这一讨论尚处于非常早期的阶段。科技网站 The Information 在本月报道称，苹果也曾与百度进行谈判，希望在 iPhone 中整合百度的 AI 模型，但是谈判遇到了挫折，原因是技术问题，其中包括双方在使用 iPhone 用户数据训练 AI 模型方面的争执。
82 |
83 | 截至发稿，字节跳动不予置评。苹果和腾讯尚未回复置评请求。（来源：IT之家）
84 |
85 | ## 提案
86 |
87 | ### 通过的提案
88 |
89 | [SE-0450](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0450-swiftpm-package-traits.md "SE-0450") **Package 特征** 提案通过审查。该提案已在 **第六十四期周报** 正在审查的提案模块做了详细介绍。
90 |
91 | ## Swift论坛
92 |
93 | 1) 讨论[建议：解决边界安全问题](https://forums.swift.org/t/suggestion-tackle-bounds-safety/76516 "建议：解决边界安全问题")
94 |
95 | 在 Swift 论坛中关于界限安全的讨论中，作者强调界限安全问题的解决应更多依赖开发者优化代码逻辑，而非语言提供额外的安全保障，同时也指出通过合理的优化策略，可以在保证内存安全的同时减少性能开销。
96 |
97 | 1. 作者承认由于索引越界或范围不正确造成的生产环境崩溃问题，但认为这种问题更多源于开发者的代码习惯，而非语言本身的问题。通过经验积累，作者学会了避免直接操作未知值的索引或范围，从而减少此类问题的发生。
98 | 2. 针对在每次下标操作时都检查索引的提议，作者认为这是过于极端的做法。代码中通常存在“入口点”对索引进行验证，一旦索引通过验证，重复检查显得多余。
99 | 3. 当前行业推动的“内存安全”语言主要是因为传统的方法难以扩展。然而，这种方法无法完全避免因“远程”操作（如更改底层存储）导致索引失效的漏洞，这可能导致更难调试的崩溃或代码安全问题。
100 | 4. 优化界限检查仍有可能。在 WebURL 中，作者自行实现了一种高效的界限检查方法，专注于速度，并尽量让编译器优化掉不必要的检查。
101 | 5. 作者计划未来在引入 Span（生命周期保证）后，将这一界限检查策略集成到新包中发布。
102 |
103 | 2) 讨论[[第二次审查] SF-0007：Subprocess](https://forums.swift.org/t/review-2nd-sf-0007-subprocess/76547 "[第二次审查] SF-0007：Subprocess")
104 |
105 | 在 SF-0007 提案的第二次审查中，总体来看，SF-0007 提案为 Swift 引入了一个潜力巨大的子进程 API，但在细节上还需要进一步优化和澄清，尤其是在跨平台一致性、闭包隔离、性能优化等方面。、
106 |
107 | 1. 第一次审查总结：
108 |
109 | 该提案得到了很多积极的评论，认为这是现有 Process API 的良好替代方案。然而，也有一些需要作者进一步澄清的问题，包括如何管理存活时间长于父进程的子进程，如何在进程间传递输出，以及一些平台特定 API 的处理问题。
110 |
111 | 2. 开发者反馈：
112 |
113 | * 闭包发送：一些方法要求闭包是发送类型（sending），这使得它们在与其他代码组合时变得不那么容易。希望能探讨是否可以重构实现，使其不需要这一要求。
114 | * 闭包隔离：提案中的方法似乎缺少对“隔离”（isolated）的参数，这在使用 actor 隔离的上下文中会导致数据竞争问题。
115 | * AsyncSequence 的性能问题：讨论了使用 AsyncSequence 可能导致的性能问题，并希望能进一步基准测试。
116 | * 平台特定类型：提案中使用了像 pid_t 和 DWORD 这样的平台特定类型，是否可以考虑直接使用 Int 来代替？
117 | * ProcessIdentifier 类型：关于 ProcessIdentifier 的命名和不同平台的属性存在一定的疑问，是否可以在所有平台上统一为 .value？
118 | * 未管理的子进程：有观点认为，未管理的子进程应与文件描述符的直接传递解耦，避免混合不同的概念。
119 | * 使用 FileDescriptor 和 FilePath：目前 swift-system 并不包含在工具链中，因此提案中如何在公有 Foundation API 中使用这两个类型仍需进一步讨论。
120 | * 拆解顺序：提案中的拆解方法需要更明确的文档说明，以避免使用者产生混淆。
121 | * ExecutionResult 的 Sendable 类型：提案中 ExecutionResult 需要一个 Sendable 类型，但为何必须是 Sendable 类型仍不清晰。
122 | * 小修改建议：建议使用更长的泛型参数名称，提供更常见的信号类型，调整 sendSignal 的参数标签等。
123 |
124 | 3) 讨论[LSP 与 CMake 和 nightly 工具链集成](https://forums.swift.org/t/lsp-integration-with-cmake-and-nightly-toolchains/76508 "LSP 与 CMake 和 nightly 工具链集成")
125 |
126 | 在关于 LSP 集成与 CMake 和夜间工具链的讨论中，作者提出在集成 LSP 与 CMake 的过程中，开发者应灵活选择合适的工具链，并关注生成文件的正确配置，特别是在处理项目构建和编译标志时。VSCode 提供了更好的自定义工具链支持，而 Xcode 的兼容性可能有限。
127 |
128 | 1. Xcode 与工具链支持：
129 |
130 | Xcode 的工具链支持存在不稳定性，开发者可能会遇到兼容性问题。相比之下，VSCode 的 Swift 插件提供了更好的工具链设置功能，允许用户自定义工具链，并应用于所有功能。但 Xcode 会使用其内部版本的工具链，且在处理苹果平台时，可能无法满足工具链的要求。
131 |
132 | 2. 构建问题与建议：
133 |
134 | 有些用户在尝试构建项目时遇到问题。特别是，对于使用 CMake 的项目，可能需要尝试不同的生成器（如 CMake generate 或 Ninja generate），以确定哪个适合自己的项目。用户也应该检查生成的文件，确保所有文件都列在其中。
135 |
136 | 3. 使用 compile_flags.txt：
137 |
138 | 对于有库的项目，建议使用 `compile_flags.txt` 风格的配置，而不仅仅是默认的 CMake 配置。这可以帮助更好地管理编译标志。
139 | 4. 配置文件与生成问题：
140 |
141 | 一些配置（如 `generatedFilesPath` 或 index）可能可以简化生成过程，避免需要单独的 `compile_commands.json` 文件。虽然目前尚不明确如何完全实现这一点，但仍建议通过配置文件进一步探索解决方案。
142 |
143 | 4) 讨论[在 @Sendable 中捕获 self……请停止它！](https://forums.swift.org/t/capture-of-self-in-a-sendable-please-make-it-stop/76463 "在 @Sendable 中捕获 self……请停止它！")
144 |
145 | 在关于 `@Sendable` 的讨论中，作者指出 `@Sendable` 和 `@unchecked Sendable` 机制的设计目的是为了帮助开发者捕捉并发问题，并避免潜在的并发错误。虽然开发者可以选择关闭这些警告，但需要承担起确保线程安全的责任，否则可能会导致数据损坏和崩溃。
146 |
147 | 1. 编译器的警告作用：
148 |
149 | 编译器发出的警告并非针对开发者，而是为了提醒潜在的并发问题，尤其是可能发生的不安全访问。编译器认为，当模型（通常是引用类型）被并发访问时，可能会引发并发问题，建议开发者审查代码。
150 |
151 | 2. @unchecked Sendable 使用：
152 |
153 | 如果开发者确定自己能安全地管理同步问题，可以通过标记类型为 `@unchecked Sendable` 来告诉编译器“我能确保这是安全的”，即使编译器无法进行进一步的检查。这是开发者对编译器的一种承诺，表明他们将负责确保并发安全。
154 |
155 | 3. 崩溃的有效性：
156 |
157 | 如果开发者违反了这种承诺并进行了不安全的访问，崩溃是合理的。处理并发问题时，编译器会倾向于立即崩溃，而不是让潜在的错误悄悄存在，避免数据损坏。
158 |
159 | 4. 编译器与开发者的关系：
160 |
161 | 尽管开发者可能感到编译器过于严格或烦人，但从编译器的角度，严格的并发检查有助于避免错误，确保代码的安全性。这类似于 C/C++ 等语言中的指针操作，虽然它们提供了更多自由，但也容易导致空指针访问等错误。
162 |
163 | 5. @unchecked Sendable 是否关闭警告：
164 |
165 | `@unchecked Sendable` 不会影响运行时，而是作为一个标记协议，告诉编译器在并发访问时可以放心地传递类型，但开发者需要对并发安全负责。如果不小心使用了类型，可能会导致并发错误。
166 |
167 | 5) 提议[Expose attosecond representation of Duration](https://forums.swift.org/t/pitch-expose-attosecond-representation-of-duration/76522 "Expose attosecond representation of Duration")
168 |
169 | 在关于 Duration 类型 attosecond 表示的提案中，作者通过引入对 Int128 类型的支持，使 Duration 类型更易于使用，特别是在需要高精度时间计算的场景中，减少了冗余代码，提高了性能和可读性。
170 |
171 | 1. 提案介绍：
172 |
173 | 该提案的目的是通过引入新的 Int128 类型，允许开发者更方便地访问 Duration 类型的飞秒（attosecond）表示，并简化从飞秒创建 Duration 值的过程。
174 |
175 | 2. 当前 Duration 类型的局限性：
176 |
177 | 当前的 Duration 类型有两种方式来构造和分解：一种是低位和高位的属性 `_low` 和 `_high`，另一种是通过 components 属性将其分解为秒和飞秒。虽然这些方式有效，但在处理 Duration 的总飞秒表示时存在一些局限性。例如，要生成一个随机 Duration，开发者目前需要编写冗长且低效的代码。
178 |
179 | 3. 提案的动机与解决方案：
180 |
181 | 通过引入 Int128 类型支持，提案简化了这一过程。开发者可以通过新的计算属性 attoseconds 和新的初始化器 `init(attoseconds: Int128)` 直接处理 Duration 的飞秒表示，从而避免了复杂的分解和运算。
182 |
183 | 4. 详细设计：
184 |
185 | 新提案通过将 `_low` 和 `_high` 属性统一为一个 Int128 类型的表示，提供了更简洁高效的 API。新增的属性 attoseconds 返回 Duration 的总飞秒数，而新的初始化器允许通过传入一个 Int128 来直接创建 Duration 实例。
186 |
187 | ## 推荐博文
188 |
189 | [SwiftUI 中 UIGestureRecognizerRepresentable 协议使用](https://swiftwithmajid.com/2024/12/17/introducing-uigesturerecognizerrepresentable-protocol-in-swiftui/ "SwiftUI 中 UIGestureRecognizerRepresentable 协议使用")
190 |
191 | **摘要：** 这篇博客介绍了 SwiftUI 新增的 `UIGestureRecognizerRepresentable` 协议，用于将 UIKit 的手势识别器包装并引入 SwiftUI 视图。通过实现 `makeUIGestureRecognizer` 创建手势，并在 `handleUIGestureRecognizerAction` 中处理状态和动作，还可通过 `makeCoordinator` 设置手势代理以增强灵活性。该协议特别适合自定义复杂手势，如检查标记手势或圆形手势，是 SwiftUI 内置手势的有力补充。
192 |
193 | [iOS sizeThatFits 和 sizeToFit的区别](https://juejin.cn/post/7448060281766248459/ "iOS sizeThatFits 和 sizeToFit的区别")
194 |
195 | **摘要：** 摘要：这篇博客探讨了 iOS 中 `sizeThatFits` 和 `sizeToFit` 的区别及应用。
196 | `sizeThatFits` 用于计算视图在特定约束下的最佳尺寸，但不会修改视图的实际大小，它更灵活，适合需要自定义尺寸计算的场景。而 sizeToFit 调用 sizeThatFits 计算后，会直接调整视图的 frame 以适应内容，适合简单的自适应布局。
197 |
198 | 通过 UILabel 的示例，博客展示了 `sizeThatFits` 如何返回最佳尺寸供开发者使用，以及 sizeToFit 如何直接更新视图大小。对于复杂布局，可以通过重写 `sizeThatFits` 来实现定制规则。
199 |
200 | 总结来说，`sizeThatFits` 提供更多控制，适用于复杂需求；sizeToFit 简单直接，适合快速适配。理解两者的区别，有助于更高效地进行视图布局调整。
201 |
202 | [Swift 进阶；泛型](https://juejin.cn/post/6963841629270900767/ "Swift 进阶；泛型")
203 |
204 | **摘要：** 这篇文章深入介绍了 Swift 中的泛型特性。泛型作为 Swift 最强大的特性之一，让开发者能够编写灵活且可重用的代码。文章从基础的泛型函数讲起，逐步深入到泛型类型、类型约束、关联类型等进阶概念，最后探讨了泛型 Where 分句的高级用法。通过大量实例代码，详细阐述了如何在实际开发中运用泛型来提高代码的灵活性和复用性，是一篇面向想要掌握 Swift 泛型特性的开发者的完整指南。
205 |
206 | ## 话题讨论
207 |
208 | **冬天洗澡，一定是很多人都非常纠结的事情，冬天洗澡真的太冷了，冬天你多久洗一次澡？**
209 |
210 | 1. 一天一洗。
211 | 2. 两天一洗。
212 | 3. 三天一洗。
213 | 4. 其它，看情况
214 |
215 | 欢迎在文末留言参与讨论。
216 |
217 | ## 关于我们
218 |
219 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
220 |
221 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
222 |
223 |
224 |
225 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
226 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_7.md:
--------------------------------------------------------------------------------
1 |
2 | ## 前言
3 |
4 | **LeetCode 算法**到目前我们已经更新了 5 期，我们会保持更新时间和进度，每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。
5 |
6 | [Xcode 13.2 beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Build-System "Xcode 13.2 beta") 中有一项新功能，可以通过使用更多 CPU 内核来加快构建速度。这个新的构建系统是可选的，所以你必须启用它。
7 |
8 | > 为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与**周报编辑**，同时邀请赞助商对我们平台赞助支持。
9 |
10 | ## 新闻和社区
11 |
12 | **Nicole Jacque** 向我们介绍了 [Swift 5.6 发布流程](https://forums.swift.org/t/swift-5-6-release-process/53412 "Swift 5.6 Release Process")的最新情况。
13 |
14 | **Mishal Shah** 通知我们[更新了 swift:main 的 llvm-project 分支](https://forums.swift.org/t/updating-llvm-project-branch-for-swift-main/53438 "Updating llvm-project branch for swift:main")。
15 |
16 | **John Sundell** 宣布了 [CollectionConcurrencyKit](https://github.com/JohnSundell/CollectionConcurrencyKit "CollectionConcurrencyKit") —— 一个轻量级的 Swift 包，他将所有符合 `Sequence` 协议的 Swift 集合添加了标准 `map`、`flatMap`、`compactMap` 和 `forEach API` 的异步和并发版本。
17 |
18 | **Steven Van Impe** [在高等教育中引入了 Swift](https://forums.swift.org/t/introducing-swift-in-higher-education/53445 "Introducing Swift in higher education")。
19 |
20 | **Mishal Shah** 向我们通报了 Swift 项目的[假期时间表](https://forums.swift.org/t/holiday-schedule/53507 "Holiday Schedule")。
21 |
22 | **Leonardo Maia Pugliese** 写了一篇文章[解释使用递归链接列表](https://holyswift.app/reverse-reverse-linked-list-linked-list-using-recursion "List : Using Recursion")。
23 |
24 | **Antoine van der Lee** 在博客文章中[解释了 Swift 中的属性包装器](https://www.avanderlee.com/swift/property-wrappers/ "Property Wrappers in Swift explained with code examples")。
25 |
26 | ## 同意的提案
27 |
28 | SE-0326 [Multi-statement 闭包参数/结果类型推断]( https://forums.swift.org/t/accepted-se-0326-multi-statement-closure-parameter-result-type-inference/53502 "Multi-statement closure parameter/result type inference")已被接受。
29 |
30 | ## 拒绝的提案
31 |
32 | **SE-0327** 被拒绝[重新进行修订](https://forums.swift.org/t/returned-for-revision-se-0327-on-actors-and-initialization/53447 "SE-0327: On Actors and Initialization")。
33 |
34 | 审查讨论集中在初始化模型的复杂性上，并发现了一个更简单的模型，应该更容易推理。核心团队已退回此提案进行修订，以调查此新模型。感谢所有参与的人！
35 |
36 | ## 正在审查的提案
37 |
38 | **SE-0329：** `Clock`, `Instant`, `Date`, 和 `Duration` 正在[审查中](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309 "Clock, Instant, Date, and Duration")。
39 |
40 | **时间的概念可以分为三个不同的部分：**
41 |
42 | 1. 提供现在概念的项目以及在给定时间点后醒来的方式
43 | 2. 时间点的概念
44 | 3. 时间测量的概念
45 |
46 | 这三个项目分别是一个时钟、一个瞬间和一个持续时间。时间测量可用于多种类型的 API，从高级网络连接超时概念到休眠任务的时间量。目前，测量时间类型的 API 使用 `NSTimeInterval`（又名 `TimeInterval`）、`DispatchTimeInterval`，甚至 `timespec` 等类型。
47 |
48 | ## Swift 论坛
49 |
50 | ### I
51 |
52 | **Ilias Karim** 提议将 [notContains](https://forums.swift.org/t/pitch-not-contains/53305 "notContains") 添加到标准库。
53 |
54 | 在 Swift 中，使用 `keypath` 符号过滤可以让函数式编程变的更加简洁和可读。
55 |
56 | 然而，没有一种直观的标准库方法可以按布尔值相反的方向过滤。我之前提议 `.toggled` 或 `.isFalse`，但是被驳回了。
57 |
58 | ### II
59 |
60 | **Karl** 提议对 [RandomNumberGenerator](https://forums.swift.org/t/filling-buffers-using-randomnumbergenerator/53324 "RandomNumberGenerator") 完善两个小功能。
61 |
62 | 1. 填充缓冲区
63 | 2. 静态成员语法
64 |
65 | ### III
66 |
67 | **Richard Wei** 提出了一个关于[强类型正则表达式捕获](https://forums.swift.org/t/pitch-strongly-typed-regex-captures/53391 "Strongly Typed Regex Captures")的想法。
68 |
69 | 捕获组是正则表达式的常用组件，允许程序员从匹配的输入中提取信息。捕获组将多个字符收集在一起作为一个单元，可以在正则表达式中反向引用，并在成功匹配的结果中访问。
70 |
71 | ### IV
72 |
73 | **Joseph Heck** 开始讨论术语问题 —— `behaviors`、`shell` 和 `possible reductions`。
74 |
75 | 我会回答 “Yep, these could be all implementation details”。在挖掘 `swift-distributed-actor` 的源代码后，我了解了一些信息（`basic actor concept`, `mailboxes`, 和 `messages`）。
76 |
77 | 分布式 actors 代码使用了一些我不太熟悉的术语和措辞，大部分我可以通过推断和猜测知道是什么意思和关系，但是我认为最好是弄清楚他们之间的相互关系。
78 |
79 | ### V
80 |
81 | **Ethan Kusters** 提出了非框架文档演示的改进。
82 |
83 | 并不是所有的 `Swift-DocC` 文档都是用框架构建的。在自定义工作流程中，Swift-DocC 将提供任何符号图形输入构建文档，例如 Swift-DocC 在 Swift.org 上的用户文档。然而不管符号图形的内容是什么，Swift-DocC 都将此文档描述为最上层页面上的“框架”。
84 |
85 | 例如，当 Swift-DocC 在 Swift.org 上的用户文档是用作“工具”，而不是“框架”时，在最上层页面上被描述为“框架”。
86 |
87 | ### VI
88 |
89 | **Tom Doron** 基于 result builders 提出了 [SwiftPM](https://forums.swift.org/t/pre-pitch-swiftpm-manifest-based-on-result-builders/53457 "SwiftPM Manifest based on Result Builders") 清单。
90 |
91 | `Swift Package Manager`（以下简称 SwiftPM）是在 2016 年 Swift 开源时发布的。SwiftPM 使用一个名为 `Package.swift` 的文件，用户可以用它来描述包的源结构、构建工件（例如构建生成的任何可执行文件或库）以及 对其他包的任何依赖。
92 |
93 | SwiftPM 的清单是一个 Swift 程序（各种脚本），SwiftPM 在安全沙盒中作为单独的进程构建和执行，以生成代表所需包配置的静态数据模型。 目前，静态表示基于 JSON，该 JSON 的详细内容是内部实现细节。 JSON 模型后来被反序列化并加载到父进程内存空间，从而驱动 SwiftPM 的工作流，如依赖解析、构建、测试等。
94 |
95 | ### VII
96 |
97 | **Konrad ktoso Malawski** 分享了一个实现[分布式 actor 隔离](https://forums.swift.org/t/proposal-distributed-actor-isolation/53460 "Distributed Actor Isolation")的提议。
98 |
99 | 该提案仅侧重于支持分布式 actor 所需的隔离规则，并从大型整体分布式 actor `pitch 8` 中分离出来。我们的目的是提出这个非常大的提案的各个部分，作为单独但是又相互关联的提案，类似于去年引入 `Swift Concurrency` 的方式。通过这种方式，我们希望保持内容数量的可审查性，并且讨论也集中在手头的特定主题上。
100 |
101 | ### VIII
102 |
103 | **Holly Borla** 提出了一项 [Introduce existential `any`](https://forums.swift.org/t/pitch-introduce-existential-any/53520 "Introduce existential any")的提案。
104 |
105 | Swift 中的现有类型具有一个非常轻量级的拼写：类型上下文中的普通协议名称表示存在类型。多年来，这已经从引起混乱上升到**主动危害**的程度，导致程序员走上了错误的道路，一旦他们遇到值级抽象的基本限制，通常需要他们重新编写代码。该提案通过使用 any 注释这些类型，使语言中的存在类型的影响变得明确。
106 |
107 | ## 推荐博文
108 |
109 | [LeetCode - #5 求最长的镜像字符串](https://mp.weixin.qq.com/s/XUY2DCQfRVPmt-5cXRvRag)
110 |
111 | [Swift 编译器 Crash—Segmentation fault 解决方案](https://mp.weixin.qq.com/s/AiMkjBRg-UHEpqv5WsGyGA)
112 |
113 | [狐友 iOS 客户端埋点的前世今生](https://mp.weixin.qq.com/s/AacxlJd315kdy9N73dRnyw)
114 |
115 | [从野指针探测到对iOS 15 bind 的探索](https://mp.weixin.qq.com/s/OG5WQR3m-8G0617yoEGgvg)
116 |
117 | [iOS 如何监测 FPS](https://mp.weixin.qq.com/s/O9ABm4lntZHmMaDcwNAoFQ)
118 |
119 | ## 关于我们
120 |
121 | 公众号是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。欢迎关注公众号：**Swift社区**，后台点击进群，联系我们获取更多内容。
122 |
123 |
124 |
125 |
126 | 感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。周报仓库：https://github.com/SwiftCommunityRes
127 |
128 | 后续还会翻译大量资料到我们公众号，有感兴趣的朋友，可以加入我们，扫码添加微信
129 |
130 |
131 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_79_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_8.md:
--------------------------------------------------------------------------------
1 |
2 | ## 前言
3 |
4 | 在 199 期的 Swift 周报中，负责人 [Kristaps Grinbergs](https://twitter.com/fassko) 向所有读者发出邀请，内容如下：
5 | > 大家好！ 我真心希望你们享受完感恩节，并且能够和你所爱的人一起度过这个假期。 也许你们中的一些人甚至玩过钱德勒发明的在 6 分钟内命名所有 50 个州的游戏。
6 |
7 | > 感恩节之后的这段时间对 Swift 团队来说收获颇丰，今天有很多活动要讨论。 但在我们开始之前，我想利用这个机会说下一期将是我的最后一期，也许是这个项目的最后一期。 如果有人有兴趣接替我的职责，请告诉我。 我很想看到这个项目在我离开后继续存在并蓬勃发展。
8 |
9 |
10 | > 为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与**周报编辑**，同时邀请赞助商对我们平台赞助支持。
11 |
12 | ## 新闻和社区
13 |
14 | **Keith Smiley** 分享了有关 Swift 5.5 的更新及其[精选分类过程](https://forums.swift.org/t/5-5-cherry-pick-triage-process/53574 "5.5 cherry pick triage process")。
15 |
16 | **John Sundell** 写了[一篇文章](https://www.swiftbysundell.com/articles/count-vs-isEmpty/ "Using count vs isEmpty to check whether a collection contains any elements")，探讨如何使用 `count` 与 `isEmpty` 来检查集合是否包含任意元素。
17 |
18 | **Will Lisac** 在推特上表示，适用于 `Raspberry Pi` 的 [Swift 5.5 Docker 镜像](https://github.com/wlisac/swift-on-balena "Swift on Balena") 现已可用。
19 |
20 | 由 **Feli** 创作的精彩[插图](https://fbernutz.github.io/images/summaries-ios-interview-topics/swift-evolution.jpg)。 她在各种会议上的[绘画作品](https://fbernutz.github.io/sketchnotes/)值得一看。
21 |
22 | **Max Desiatov** 宣布 [SwiftWasm 5.5.0](https://blog.swiftwasm.org/posts/5-5-released/ "SwiftWasm 5.5.0 is now available") 现已可用。
23 |
24 |
25 | ## 同意的提案
26 | **SE-0328** `Structural opaque result` 类型已被[接受并进行了修改](https://forums.swift.org/t/accepted-with-modifications-se-0328-structural-opaque-result-type/53789 "[Accepted with Modifications] SE-0328: Structural opaque result type")。
27 |
28 | 在审核期间，主要讨论了两个方面：
29 | - 可选类型的拼写。 提案将其保留为 ` (some P)? `，尽管 `some P?` 更简洁，可能被作为语法糖。 核心团队更同意这种保守的方法，稍后可以在对该功能有更多经验后重新考虑。
30 | - 当返回函数类型即 `f() -> (some P) -> Void` 时，在“消费”而不是“生产”位置使用 `some`。 `some` 关键字的其他用途正在讨论中，并且担心与某些未来特性存在潜在冲突。 由于在消费位置使用 `opaque result` 类型不是特别有用（这种函数在所有情况下都是不可调用的），因此核心团队决定将这种使用子集化，目前仅在返回函数类型的返回值中要求 `opaque result` 类型。
31 |
32 |
33 |
34 | ## 正在审查的提案
35 |
36 | **SE-0332**：[包管理器命令插件](https://forums.swift.org/t/se-0332-package-manager-command-plugins/53769 "Package Manager Command Plugins")正在审查中。
37 |
38 | **SE-0303** 引入了在 SwiftPM 中定义构建工具插件的能力，允许在构建过程中自动调用自定义工具。 该提案扩展了该插件支持以允许定义自定义命令插件——用户可以直接从 SwiftPM CLI 或从支持 Swift 包的 IDE 调用的插件，以便对其包执行自定义操作。
39 |
40 | **SE-0331**: [从不安全的指针类型中删除 `Sendable` 一致性](https://forums.swift.org/t/se-0331-remove-sendable-conformance-from-unsafe-pointer-types/53768 "Remove Sendable conformance from unsafe pointer types")正在审查中。
41 |
42 | **SE-0302** 引入了 `Sendable` 协议，包括对各种语言结构的 `Sendable` 要求，各种标准库类型对 `Sendable` 的一致性，以及非公共类型隐式符合 `Sendable` 的推理规则。
43 |
44 | `Sendable` 的使用经验表明，这种表述是不必要的危险，并且会对隐式一致性产生意想不到的负面影响。
45 |
46 | **SE-0333**：正在审查 [`withMemoryRebound` 的扩展可用性](https://forums.swift.org/t/se-0333-expand-usability-of-withmemoryrebound/53799 "Expand usability of withMemoryRebound")。
47 |
48 | 函数 `withMemoryRebound(to:capacity:_ body:)` 执行一个闭包，同时将一定范围的内存临时绑定到与被调用者绑定的类型不同的类型。 我们建议解除 `withMemoryRebound` 的一些显着限制，并允许重新绑定到更大的类型集，以及从原始内存指针和缓冲区重新绑定。
49 |
50 | 请注意，此提案与 **SE-0334** 同时运行，这也与不安全的指针可用性有关。
51 |
52 | **SE-0334**：正在审查[指针可用性改进](https://forums.swift.org/t/se-0334-pointer-usability-improvements/53800 "Pointer Usability Improvements")。
53 |
54 | 该提案为 `UnsafePointer` 及其 `Mutable` 和 `Raw` 变量引入了一些质的改进。
55 | 1. 添加一个 API 以获取一个 `UnsafeRawPointer` 实例，该实例从其起点前进到给定的对齐方式。
56 | 2. 在给定 `UnsafePointer` 的情况下，添加 API 以获取指向聚合 `T` 的存储属性的指针。
57 | 3. 添加比较任意两种类型的指针的能力。
58 |
59 | 请注意，此提案与 **SE-0333** 同时运行，这也与不安全的指针可用性有关。
60 |
61 | ## Swift 论坛
62 |
63 | ### I
64 | **Ethan Kusters** 开始讨论[在静态托管环境中支持托管 DocC 档案](https://forums.swift.org/t/support-hosting-docc-archives-in-static-hosting-environments/53572 "Support hosting DocC archives in static hosting environments")。
65 |
66 | 这篇文章讨论了 Swift-DocC 和 Swift-DocC-Render 的增强功能，这将允许开发人员构建无需自定义路由即可托管的 DocC 档案。 这是专门为使 DocC 能够在其他静态托管环境中使用而设计的，最显着的是 GitHub Pages。
67 |
68 | 此更改旨在作为解决紧迫需求的快速解决方案，并提供普遍的好处。 但请注意，我们已经听到社区的反馈，他们希望 Swift-DocC 直接发出静态 HTML，并且此功能在优先级列表中居高不下。
69 |
70 | ### II
71 | **Sam Deane** 提出了一个想法来[实现一个默认的可初始化协议](https://forums.swift.org/t/default-initable-protocol/53723 "Default-initable Protocol")。
72 |
73 | **Kristaps Grinbergs** 遇到过工厂类型的情况，最终制定了一个协议来表示“可以使用不带参数的默认 `init` 构造这种类型”。
74 |
75 | **Kristaps Grinbergs** 发现他感到惊讶： **(a)** 这个协议是否已经存在于标准库中的某个地方，以及 **(b)** 如果 `init()` 存在，Swift 是否可以自动使任何类型符合它。
76 |
77 | ### III
78 | 一个好的[提醒](https://forums.swift.org/t/a-built-in-angle-type/53726 "A built-in Angle type")， [库 Swift Numerics](https://github.com/apple/swift-numerics) 确实存在。
79 |
80 | **Guillaume Lessard** 提出了使缓冲区切片更有用的[提案](https://forums.swift.org/t/pitch-buffer-partial-initialization-better-buffer-slices/53795 "[Pitch] Buffer Partial Initialization / Better Buffer Slices")，尤其是在缓冲区的部分初始化方面。
81 |
82 | `UnsafeBufferPointer` 系列的子序列具有 `UnsafeBufferPointer` 的所有 `[Mutable]Collection` API，但没有它们特定于缓冲区的 API。 这使得缓冲区的部分初始化以及其他任务变得困难。
83 |
84 | ## 推荐博文
85 |
86 | ### LeetCode 系列
87 |
88 | 该系列的文章中有 **5 篇 Top 100 高频题**
89 |
90 | [LeetCode - #1 两数之和](https://mp.weixin.qq.com/s/BwUa6IN4O3DWLmoMAzoFeg)
91 |
92 | 难度水平：**容易**，公司面试使用频率如下：
93 |
94 | 公司 | 频率
95 | ----|------
96 | Amazon | ★★★★★★
97 | Facebook | ★★★★★
98 | Airbnb | ★★★★★
99 | Microsoft | ★★★★★
100 | LinkedIn | ★★★★
101 |
102 | [LeetCode - #2 两数相加](https://mp.weixin.qq.com/s/wFUafzkwiLe7GtP7Uyz9Eg)
103 |
104 | 难度水平：**中等**，公司面试使用频率如下：
105 |
106 | 公司 | 频率
107 | ----|------
108 | Microsoft | ★★★★
109 | Amazon | ★★
110 | Airbnb | ★★
111 |
112 | [LeetCode - #3 最长未重复子字符串](https://mp.weixin.qq.com/s/bHLoloSfGphlBQsPXkH6pg)
113 |
114 | 难度水平：**中等**，公司面试使用频率如下：
115 |
116 | 公司 | 频率
117 | ----|------
118 | Amazon | ★★
119 |
120 | [LeetCode - #4 求两个有序数组的中间值](https://mp.weixin.qq.com/s/QKO2sD2T1H-tFUcakgHUwA)
121 |
122 | 难度水平：**困难**
123 |
124 | [LeetCode - #5 求最长的镜像字符串](https://mp.weixin.qq.com/s/XUY2DCQfRVPmt-5cXRvRag)
125 |
126 | 难度水平：**中等**，公司面试使用频率如下：
127 |
128 | 公司 | 频率
129 | ----|------
130 | Amazon | ★★
131 |
132 | >难度水平：容易、中等、困难
133 | 公司使用频率：1 ～ 6 颗 ★
134 |
135 | ### iOS 系列
136 |
137 | [戴铭的 Swift 小册子](https://mp.weixin.qq.com/s/AW1PmRU8xKXORuEDJMTNOg)
138 |
139 | 本篇是面向 Swift 零基础的同学，内容主要是一些直接可用的小例子，例子可以直接在工程中用或自己调试着看。
140 |
141 | [SwiftUI 属性包装器如何处理结构体](https://mp.weixin.qq.com/s/Uy2VY7vjFeKMU2yjh8ftsw)
142 |
143 | 更改 @state 包装的属性时是如何自动让 SwiftUI 重新调用结构体的 body 属性？
144 |
145 | [2021 互联网公司时薪排行榜出炉！微软、美团很强！](https://mp.weixin.qq.com/s/mBtydsEv3nRvNzxdV_ikcQ)
146 |
147 | 分享一个对于选择公司非常有用的参考："**互联网时薪**"。
148 |
149 | ## 关于我们
150 |
151 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
152 |
153 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的各种交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
154 |
155 |
156 |
157 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量，排名不分先后：
158 | * [张安宇@微软](https://blog.csdn.net/mobanchengshuang "张安宇")
159 | * [倪瑶@Trip.com](https://github.com/niyaoyao "倪瑶")
160 | * [戴铭@快手](https://ming1016.github.io "戴铭")
161 | * [展菲@ESP](https://github.com/fanbaoying "展菲")
162 | * [杜鑫瑶@新浪](https://weibo.com/u/3878455011 "杜鑫瑶")
163 |
164 | 周报仓库：https://github.com/SwiftCommunityRes 文章中外引链接较多，可以点击 **阅读原文** 更加方便阅读。
165 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_80_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_81_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_83_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_84_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_85_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_86_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_87_process.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | **本期是 Swift 编辑组自主整理周报的第五十期**，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
4 |
5 | Swift 周报在 [GitHub 开源](https://github.com/SwiftCommunityRes/SwiftWeekly "SwiftWeekly")，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
6 |
7 | 间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，**Swift社区**也在华丽蜕变！👊👊👊
8 |
9 | > **周报精选**
10 | >
11 | > 新闻和社区：
12 | >
13 | > 提案：
14 | >
15 | > Swift 论坛：
16 | >
17 | > 推荐博文：
18 | >
19 | > **话题讨论：**
20 | >
21 | >
22 | >
23 | >**上期话题结果**
24 |
25 |
26 | ## 新闻和社区
27 |
28 |
29 | ## 提案
30 |
31 |
32 | ## Swift论坛
33 |
34 |
35 | ## 推荐博文
36 |
37 |
38 | ## 话题讨论
39 |
40 |
41 | ## 关于我们
42 |
43 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
44 |
45 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
46 |
47 |
48 |
49 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
50 |
--------------------------------------------------------------------------------
/SwiftWeekly/SwiftWeekly_9.md:
--------------------------------------------------------------------------------
1 | ## 前言
2 |
3 | ```text
4 | 万物本末终终(In every end, there is also a beginning.)
5 | ```
6 |
7 | 这一期(200期)将是我最后一期以主要贡献者身份参与项目。我想要感谢开启这个项目的[Jesse Squires](https://twitter.com/jesse_squires)，以及相信我并接替我继续运营这个项目的[Bas Broek](https://twitter.com/BasThomas)。同样我还要感谢所有帮助撰写、审阅或提供内容的贡献者。这确实是一个社区运行的项目。谢谢！
8 |
9 | ## 播客
10 |
11 | 在Sundell 播客 Swift 的[第 110 集中](https://www.swiftbysundell.com/podcast/110/ "第 110 集")，[Tim Condon](https://twitter.com/0xTim)与[John Sundell](https://twitter.com/johnsundell)一起讨论客户端和服务端 Swift 开发人员如何利用新的内置并发系统，以及分布式和其他即将推出的语言功能如何继续下去让 Swift 在服务器上更加强大。
12 |
13 | ## 新闻和社区
14 |
15 | 六年前，即 2015 年 12 月 3 日，Swift 语言[开源](https://www.swift.org/blog/welcome/ "开源")了。
16 |
17 | Xcode 13.2 已经发布。该版本略有下降，但具有一些显著的[Swift 特性](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift "Swift 特性")。
18 |
19 | [Swift Playgrounds 4 现已推出。](https://developer.apple.com/news/?id=v868vy6e "Swift Playgrounds 4")Swift Playgrounds 是学习如何编码的最佳和最简单的方法。借助 Swift Playgrounds 4，您可以使用工具直接在 iPad 上构建 iPhone 和 iPad 应用程序，并将它们直接提交到 App Store Connect。
20 |
21 | 亚马逊网络服务[宣布](https://twitter.com/awsdevelopers/status/1466476358389874704)[Swift版本的AWS SDK](https://t.co/0x27sFTE3p "Swift版本的AWS SDK")目前可以开发者预览。
22 |
23 | [Vincent Pradeilles](https://twitter.com/v_pradeilles)发布了一段关于 Swift 标准库[的视频](https://www.youtube.com/watch?v=Ii1mDtDr3xo "Swift 标准库")。
24 |
25 | ## 提交和拉取请求
26 |
27 | [Alejandro Alonso](https://github.com/Azoy)合并了一个删除 ICU[的拉取请求](https://github.com/apple/swift/pull/40340 "ICU")。
28 |
29 | ## 同意的提案
30 |
31 | [SE-0331](https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md) 从不安全的指针类型中删除`Sendable`已被[接受](https://forums.swift.org/t/accepted-se-0331-remove-sendable-conformance-from-unsafe-pointer-types/53979 "删除 Sendable")。
32 |
33 | [SE-0332](https://github.com/apple/swift-evolution/blob/main/proposals/0332-swiftpm-command-plugins.md) 包管理器命令插件已[接受修改](https://forums.swift.org/t/accepted-with-modifications-se-0332-package-manager-command-plugins/54074 "包管理器命令插件")。
34 |
35 | ## 正在审查的提案
36 |
37 | [SE-0335](https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md)：介绍存在 `any` 的[审查](https://forums.swift.org/t/se-0335-introduce-existential-any/53934 "any")。
38 |
39 | Swift 中的存在类型有一个非常轻量级的拼写：类型上下文中的协议名称意味着存在类型。多年来，这已经通过引起混乱上升到**主动危害**的程度，导致程序员走上错误的道路，一旦他们遇到[值级抽象](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials "值级抽象")的基本[限制](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials "限制")，通常需要他们重新编写代码。该提案通过使用 `any` 明确存在类型的巨大影响。
40 |
41 | [SE-0336](https://github.com/apple/swift-evolution/blob/main/proposals/0336-distributed-actor-isolation.md)：分布式 actor 隔离的[审查](https://forums.swift.org/t/se-0336-distributed-actor-isolation/53939 "分布式 actor 隔离")。
42 |
43 | 随着最近在语言中引入了[actors](https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md "actors")，Swift 获得了用于编写*线程安全*并发程序的强大而基础的构建器。该提案是一系列通过*分布式 actor*的概念扩展 Swift 的 actor 运行时的提案中的第一个，让开发人员不仅可以在本地环境中，还可以在分布式环境中利用 actor 模型。
44 |
45 | 对于分布式参与者，我们承认我们生活的世界越来越多地围绕分布式系统构建，我们应该为开发人员提供更好的工具方便在这些环境中工作。我们的目标是简化和推动 Swift 中分布式系统编程的最新技术，就像我们把利用`local actors`来并发编程和`Swift's structured concurrency`方法嵌入到Swift语言中。
46 |
47 | 该提案侧重于扩展分布式actors的`actor隔离`和类型检查。
48 |
49 | [SSWG-0018](https://github.com/swift-server/sswg/blob/main/proposals/0018-mqtt-nio.md)：MQTTNIO建议是[审查](https://forums.swift.org/t/sswg-0018-mqttnio-proposal/54004 "MQTTNIO")。
50 |
51 | 有许多 Swift MQTT 库，但很多都不是建立在 SwiftNIO 之上的。许多只支持一个版本的协议或不提供 WebSocket 或 TLS 连接。MQTTNIO 提供了所有这些。该库最近还新增了新的的 Swift 并发 API。
52 |
53 | [SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md)：关于 Actors 和初始化正在[接受第二次审查](https://forums.swift.org/t/se-0327-second-review-on-actors-and-initialization/54093 "关于 Actors 和初始化")。
54 |
55 | 针对[第一次审查 1 的](https://forums.swift.org/t/se-0327-on-actors-and-initialization/53053 "第一次审查")反馈，该提案经历了多次修改，作者总结为：
56 |
57 | 1. 与 actor 无关的 actor 初始值设定项现在允许您从 `nonisolated` 方法中执行通常可以执行的任何操作。作为交换，Swift 会自动拒绝可能不安全的存储属性的访问。这是[问题描述](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#overly-restrictive-non-async-initializers)和[建议的解决方案 3](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#initializers-with-nonisolated-self)。
58 | 2. Actor 的析构器不能再访问实例的不可发送的存储属性。这是[问题描述](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#data-races-in-deinitializers)和[建议的解决方案 1](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#deinitializers)
59 | 3. 类型的存储属性的默认值在非隔离上下文中进行评估。这是[问题描述](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#stored-property-isolation)和[建议的解决方案](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#global-actor-isolation-and-instance-members)
60 | 4. 不再需要定义一个 `actor` 的委托初始化器时候加上 `convenience` 关键字。这是其委托初始化程序的[问题描述](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#initializer-delegation)和[建议规则](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#delegating-initializers)，仍在 `Sendability` 部分。
61 |
62 | ## Swift论坛
63 |
64 | [Evan Wilde](https://forums.swift.org/u/etcwilde) 提出了[一个建议](https://forums.swift.org/t/pitch-unavailability-from-asynchronous-contexts/53877 "@unavailableFromAsync 属性") `@unavailableFromAsync`属性。
65 |
66 | Swift 并发模型允许任务在不同的线程上挂起和恢复。虽然这种行为允许计算资源的更高效用，但有一些令人讨厌的陷阱可能会出现在毫无戒心的程序员身上。一个陷阱是`pthread_mutex_t`从与持有锁的线程不同的线程解锁的未定义行为。跨暂停点读取和写入线程本地存储也可能导致意外行为，因为操作可能会在不同的线程上恢复。
67 |
68 | [Tom Doron](https://twitter.com/tomerdoron)提出了[一个想法](https://forums.swift.org/t/pitch-package-manager-statically-link-swift-runtime-libraries-by-default-on-supported-platforms/53900 "静态链接 Swift")，即默认情况下在支持的平台上静态链接 Swift 运行时库。
69 |
70 | Swift 5.3.1 引入[了在 Linux 上静态链接 Swift 运行时库](https://forums.swift.org/t/static-linking-on-linux-in-swift-5-3-1/)。使用此功能，用户可以 `--static-swift-stdlib` 在调用 SwiftPM 命令（或长格式 `-Xswiftc -static-stdlib`）时设置标志，以便将 Swift 运行时库静态链接到程序中。
71 |
72 | 在某些平台上，例如 Linux，这通常是链接程序的首选方式，因为程序更容易部署到目标服务器或以其他方式共享。
73 |
74 | 该提案探索了在此类平台上构建可执行程序时使其成为 SwiftPM 的默认行为。
75 |
76 | [Frederick Kellison-Linn](https://forums.swift.org/u/jumhyn)[提议](https://forums.swift.org/t/swift-6-reconsider-escaping-for-optional-function-type-parameters/53932 "可选函数")重新考虑`@escaping`可选函数型参数。[
77 | Kavon Farvardin](https://swiftweeklybrief.com/issue-200/)更新[了](https://forums.swift.org/t/pitch-2-on-actors-and-initialization/53972)关于 Actors 和 Initialization[的提案](https://forums.swift.org/t/pitch-2-on-actors-and-initialization/53972 "Actors 和 Initialization")。
78 |
79 | 由于提案与第一次审查有很大不同，所以这类似于竞标。下面是所提议的主要功能的非常非正式且不完整的摘要，以及一些指向文档本身的链接以获取更多详细信息：
80 |
81 | 1. 与actor 无关的actor 初始值设定项现在允许您从`nonisolated`方法中执行通常可以执行的任何操作。作为交换，Swift 会自动拒绝对可能不安全的存储属性的访问。这是[问题描述 2](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#overly-restrictive-non-async-initializers)和[建议的解决方案 1](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#initializers-with-nonisolated-self)。
82 | 2. Actor 的析构器不能再访问实例的不可发送的存储属性。这是[问题描述 1](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#data-races-in-deinitializers)和[建议的解决方案](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#deinitializers)
83 | 3. 如果类型的隔离与其初始值设定项不兼容，则类型的存储属性不能具有默认值。这是[问题描述](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#stored-property-isolation)和[建议的解决方案](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#global-actor-isolation-and-instance-members)
84 | 4. 不再需要定义一个`actor`的委托初始化器时候加上`convenience`关键字。这是其委托初始化程序的[问题描述 3](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#initializer-delegation)和为其委托初始化器[提出的规则 2](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#delegating-initializers),仍在`Sendability`部分。
85 |
86 | ## 推荐博文
87 |
88 | ### LeetCode 系列
89 |
90 | [LeetCode - #11 盛最多水的容器（前100）](https://mp.weixin.qq.com/s/EGBbg43Rz79mP5LbVn8GUA)
91 |
92 | [LeetCode - #12 整数转罗马数字](https://mp.weixin.qq.com/s/PylM9mU7K_XxeyvRyqZBUQ)
93 |
94 | [LeetCode - #13 罗马数字转整数](https://mp.weixin.qq.com/s/QU3LR1OKqgqMhIIV_TyTzA)
95 |
96 | [LeetCode - #14 最长公共前缀](https://mp.weixin.qq.com/s/9ClkaKPjv1zNp72NPh9-9Q)
97 |
98 | ### iOS 系列
99 |
100 | [解决 iOS 15 上 APP 莫名其妙地退出登录](https://mp.weixin.qq.com/s/_a5DddYgQHKREi5VoEeJyg)
101 |
102 | [使用 Swift 搭建一个 HTTP 代理](https://mp.weixin.qq.com/s/PtSVTLlnmUDMDnJB4URnHQ)
103 |
104 | [TCA - SwiftUI 的救星？(一)](https://mp.weixin.qq.com/s/EIHVrg55ChAeDfxuxSDgeg)
105 |
106 | [TCA - SwiftUI 的救星？(二)](https://mp.weixin.qq.com/s/67pMqZQ4FNhLns9lF_wBXg)
107 |
108 | ## 关于我们
109 |
110 | **Swift社区**是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 **Swift实战**、**SwiftUl**、**Swift基础**为核心的技术内容，也整理收集优秀的学习资料。
111 |
112 | 欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的各种交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
113 |
114 |
115 |
116 | 特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量，排名不分先后：
117 | [张安宇@微软](https://blog.csdn.net/mobanchengshuang "张安宇")、[戴铭@快手](https://ming1016.github.io "戴铭")、[展菲@ESP](https://github.com/fanbaoying "展菲")、[倪瑶@Trip.com](https://github.com/niyaoyao "倪瑶")、[杜鑫瑶@新浪](https://weibo.com/u/3878455011 "杜鑫瑶")、[韦弦@Gwell](https://www.jianshu.com/u/855d6ea2b3d1 "韦弦")、[张浩@讯飞](https://github.com/zhanghao19920218 "张浩")、[张星宇@ByteDance](https://github.com/bestswifter "张星宇")、[郭英东@便利蜂](https://github.com/EmingK "郭英东")
118 |
119 | 周报仓库：https://github.com/SwiftCommunityRes 文章中外引链接较多，可以点击 **阅读原文** 更加方便阅读。
120 |
--------------------------------------------------------------------------------
/SwiftWeekly/图片.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/SwiftCommunityRes/SwiftWeekly/ff06500903358fa4b4942368375dd51a01cdcbff/SwiftWeekly/图片.jpeg
--------------------------------------------------------------------------------
/res/21-GitHub-App.md:
--------------------------------------------------------------------------------
1 | # 推荐21个GitHub上好用又有趣的移动端项目（涵盖初中高阶）
2 |
3 | ## 初级篇：
4 |
5 | ### 1. R.swift
6 |
7 | 一个工具库，编译时会自动识别项目中的资源，将项目中的资源类型化，消除字面量。目前支持图片、字体、颜色、LocalizedStrings、Storyboards等等。缺点是组件化开发时可能需要修改脚本。
8 |
9 | * github地址：[https://github.com/mac-cain13/R.swift](https://github.com/mac-cain13/R.swift)
10 |
11 | ### 2. SwiftLint
12 |
13 | 一个工具库，编译时自动检查项目中不规范的Swift代码，消除不规范代码必备。可以通过编辑.swiftlint.yml来自定义规则。也支持通过brew安装，自己手动检查
14 |
15 | * github地址: [https://github.com/realm/SwiftLint](https://github.com/realm/SwiftLint)
16 |
17 | ### 3. LSUnusedResources
18 |
19 | 一个开源Mac工具App，可以分析检测项目中没用到的图片等资源。想要精简App包大小时，可以使用该工具辅助。
20 |
21 | * github地址：[https://github.com/tinymind/LSUnusedResources](https://github.com/tinymind/LSUnusedResources)
22 |
23 | ### 4. 淘系工程师个人项目
24 |
25 | 这是一个模仿网易云特效的demo，在这么demo中，可以学习到酷炫的动画效果，也可以学习到贝塞尔曲线的来龙去脉。
26 |
27 | * 项目地址：[https://github.com/LiuLei0571/jingyun_breizer](https://github.com/LiuLei0571/jingyun_breizer)
28 |
29 | ### 5. Pedometer
30 |
31 | swagger-ui一个简单轻量级的计步器，使用硬件传感器来计算步数，同时考虑到了电量使用问题，最小化电量消耗。
32 |
33 |
34 | * 项目地址：[https://github.com/j4velin/Pedometer](https://github.com/j4velin/Pedometer)
35 |
36 | ### 6. Lottie
37 |
38 | Airbnb 开发的一款能够为原生应用添加动画效果的开源工具。Lottie 目前提供了 iOS, Android, 和 React Native 版本，能够实时渲染 After Effects 动画特效。
39 |
40 |
41 | * 项目地址：[https://github.com/airbnb/lottie-android](https://github.com/airbnb/lottie-android)
42 |
43 | ##中级篇：
44 |
45 | ### 1. CollectionKit
46 |
47 | 一个Swift列表库，继承自UIScrollView，可以自行对布局、数据源、渲染进行定制扩展。能快速自由搭建好看的列表页面，比UICollectionView的使用简单，比UITableView扩展性更强。
48 |
49 |
50 | * github地址：[https://github.com/SoySauceLab/CollectionKit](https://github.com/SoySauceLab/CollectionKit)
51 |
52 | ### 2. swift-style-guide
53 |
54 | swift-style-guide 是一个关于 Swift 语法的仓库。该仓库非常详细地介绍大多数常用 Swift 语法的推格式、注释等。
55 |
56 |
57 | * WebPage地址：[https://www.raywenderlich.com/whats-new](https://www.raywenderlich.com/whats-new)
58 | * GitHub地址：[https://github.com/raywenderlich/swift-style-guide](https://github.com/raywenderlich/swift-style-guide)
59 |
60 | ### 3. Drafter
61 |
62 | Drafter是一个命令行工具，用于分析iOS工程的代码，支持Objective-C和Swift。自动解析代码并生成方法调用关系图。自动解析代码并生成类继承关系图。
63 |
64 |
65 | * github地址: [https://github.com/L-Zephyr/Drafter](https://github.com/L-Zephyr/Drafter)
66 |
67 | ### 4. 高仿短视频推荐
68 |
69 | 目前短视频 app 火爆异常，没几年已经成为国民级 app ，是时候来学习视频播放的相关知识了，下面两个项目是模仿抖音 app 的开源项目，可以作为开发者学习短视频开发的入门 demo 。
70 |
71 |
72 | * 项目地址：[https://github.com/sshiqiao/douyin-ios-objectc](https://github.com/sshiqiao/douyin-ios-objectc)
73 |
74 | ### 5. Android：Titok
75 |
76 | * 项目地址：[https://github.com/running-libo/Tiktok](https://github.com/running-libo/Tiktok)
77 |
78 | * iOS demo预览地址：[https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ebfb935983b343e4b71384119d4009df~tplv-k3u1fbpfcp-watermark.awebp](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ebfb935983b343e4b71384119d4009df~tplv-k3u1fbpfcp-watermark.awebp)
79 |
80 | * Android demo预览地址：[https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a54df25c4f104f839c6d702401e54d0b~tplv-k3u1fbpfcp-watermark.awebp](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a54df25c4f104f839c6d702401e54d0b~tplv-k3u1fbpfcp-watermark.awebp)
81 |
82 | ### 6. Google breakpad
83 |
84 | 一个跨平台的崩溃转储和分析框架和工具集合。Breakpad 可以在移除编译器调试信息后，抓取、压缩 minidump 信息，将其发送回你的服务器，然后为 C/C++ 生成调用栈。
85 |
86 | * 项目地址：[https://github.com/google/breakpad](https://github.com/google/breakpad)
87 |
88 | ### 7. 老司机周报
89 |
90 | 老司机技术周报是一个由移动开发爱好者组成的团体，是目前为数不多还在活跃的 iOS 社区组织。
91 |
92 |
93 | * 小专栏：[https://xiaozhuanlan.com/u/damonwong](https://xiaozhuanlan.com/u/damonwong)
94 | * GitHub地址：[https://github.com/SwiftOldDriver/iOS-Weekly](https://github.com/SwiftOldDriver/iOS-Weekly)
95 |
96 | ## 高级篇：
97 |
98 | ### 1. ReSwift
99 |
100 | Swift版本的 单向数据流框架。了解单向数据流思想可以参照Redux。
101 |
102 | * github地址: [https://github.com/ReSwift/ReSwift](https://github.com/ReSwift/ReSwift)
103 |
104 | ### 2. RxSwift
105 |
106 | Swift版本的 响应式编程框架，与RxJava作者相同，思想一致。Rx已经形成了完备的生态，基于Rx的网络库、列表、UI等扩展都可以在github找到。
107 |
108 | * github地址: [https://github.com/ReactiveX/RxSwift](https://github.com/ReactiveX/RxSwift)
109 |
110 | ### 3. Texture
111 |
112 | 异步渲染UI框架, 该库的设计思想对很多UI框架产生了影响。虽然入门门槛不高，但是想要理解内部实现机制还是有一定门槛的，而且由于用的人不多，这个库有一些坑比较难跨过去。
113 |
114 | * github地址：[https://github.com/TextureGroup/Texture](https://github.com/TextureGroup/Texture)
115 |
116 | ### 4. yoga
117 |
118 | 一个C++写的跨平台布局引擎，ReactNative和Texture底层都用的该库。也可以基于此库快速实现一个Flex布局框架。
119 |
120 | * github地址：[https://github.com/facebook/yoga](https://github.com/facebook/yoga)
121 |
122 | ### 5. VirtualAPK
123 |
124 | VirtualAPK是滴滴出行自研的一款优秀的插件化框架，通过将业务模块插件化，可随时更新插件来发布新功能，具备版本随时发布的能力。
125 |
126 | * 项目地址：[https://github.com/didi/VirtualAPK](https://github.com/didi/VirtualAPK)
127 |
128 | ### 6. wanAndoid
129 |
130 | 玩Android网站——努力做一个优质的 Android 站点，目前是国内比较火的Android开源社区，并且一直在持续不断的优化当中，作者已经开发了相关的 API 。
131 |
132 | * 项目地址：[https://www.wanandroid.com/index](https://www.wanandroid.com/index)
133 | * 项目地址：[https://github.com/hongyangAndroid/wanandroid](https://github.com/hongyangAndroid/wanandroid)
134 |
135 | ### 7. Epic
136 |
137 | 是一个在虚拟机层面、以 Java Method 为粒度的 运行时 AOP Hook 框架。简单来说，Epic 就是 ART 上的 Dexposed（支持 Android 5.0 ~ 11）。
138 |
139 | * 项目地址：[https://github.com/tiann/epic](https://github.com/tiann/epic)
140 |
141 | ### 8. YYKit
142 |
143 | YYKit 是 ibireme 开源的一组功能丰富的 iOS 组件，其中包括 序列化框架 YYModel、缓存框架 YYCache、富文本框架 YYText 等。
144 |
145 | * Blog地址：[https://blog.ibireme.com/](https://blog.ibireme.com/)
146 | * GitHub地址：[https://github.com/ibireme/YYKit](https://github.com/ibireme/YYKit)
--------------------------------------------------------------------------------