波報 #46 - 王國之累
Swift 大小事 2023/5/8 - 2023/5/14
💬 Pofat 的話
隨著 WWDC 的靠近，加上王國之淚的發行，社群話題少了不少，我追隨的開發者們至少有三分之一有公開宣佈進入海拉魯（有的就直接消失了吧），有些舊話題正好又浮上來，和大家聊聊。
此外，下週我又要坐飛機，沒意外的話會在機上打薩爾達休刊一週。
🌎 On Swift Community
DeepDishSwift 精彩總結
上週在芝加哥舉辦的新 Swift 研討會引起不少迴響和好評，其中的講者 Danijela 寫了一篇很完整的回顧和心得文，看完覺得參加研討會的熱血又回來了！同時 iPlayground 2023 也在籌備中，歡迎大家關注。
New access control: package
SE-0386 已被接受，這個波報 #31 有介紹過，想到還有些可以補充的，這之前大都常用 @_spi 或 @_implementationOnly 這兩個標記來替代使用， package 本質上是加強版的 @_spi （可以標記某個方法為自 定義的 scope，在其它地方 import 這個 scope 便能看到，這裡有篇文章介紹得很清楚），Swift 本身的 codebase 使用它來取代 @testable，因為 @testable 本身設計有問題，無視原始 access control 的代價就是要重新 compile ，也搞亂其它生成的 code （ 原文見此）。不過回到設計本身，現實上這需求的確存在，我們不想要暴露出去但要從外部取得存取的能力（比如 mock），用 pakcage 取代 @testable 似乎是個想法，只是每一個要用到的 method 都要標記起來，難免又和原本目的搞混，我認為若要這樣走要給一個新標記名稱，但其實只是 typealias 而己。
另外，@_implementationOnly 仍然尊重原本 module 的宣告，只是引用的 module 不會再暴露出去給外部，比如 C -> import B -> @_implementationOnly import A，那 C 看不到 A，這除了只露出應露出的介面給使用的好處外，也有 binary size 的好處（避免暴露不必要 symbol）。
Final Cut Pro And Logic Pro on iPad
Mac 上影音編輯和混音神器降臨 iPad M1，但竟然變訂閱制（$4.99/月），很多人在討論這是不是代表著 Xcode for iPad 也將到來（以 $4.99/月的姿態）。個人覺得 Xcode 的現況和我在 iPad 上多次工作的經驗來看，先不要吧。反正 Swift Playground 也是可以寫 app 啊。
SwiftUI ViewModifier 是個令人頭痛的問題
ViewModifier 在 SwiftUI 裡使用起來相當方便，你可以在許多地方 present view，修改 navigation title ，但我認為這是 scalability 的一大阻礙，第一 ViewModifier 的作用域在使用上並不明顥，你必需真正了解各個的範圍才能去推算；第二，順序／交互對象有影響，這也是一個只能靠知識來 debug 的問題，隨著越來越多功能和平台，交互的組合只會更多。SwiftUI 的哲學是讓你切分更小的 view 以維持控制能力，但我認為這不會減緩問題，短期內我希望有個像 CSS inspector 的東西減少 debug 之痛苦。
How Not To Protect Your Data With Locks
Rico Marini 是我很尊敬做 performance 的前輩，他豐富的經驗總是能指引出一個讓人避免撞上太多坑的方向，這篇列出了許多 lock 的不良使用情境，會在某天冷不防地反咬你一口那種，值得一讀。
🗣️ On Swift Forum
Xcode 14.3 的 Structured Concurrency Bug 修復
Xcode 14.3 有 Concurrency bug 會在 iOS 15.0 以下，15.2 未滿的系中發生 crash， 而且無法避免。目前這個問題己被找出原因是 libswiftCompatibility56 與 libswift_Concurrency.dylib 之間的 property 不 match，前者 back deploy 了 voucher 這功能而受影響的作業系統版本釋出的後者並未包括這個 field ，詳細修復見這個 PR。這 bug 事關重大，可能會放進 14.3 的更新中。
這個 issue 可以看出 back deploy 著實不容易，要怎麼確保或測試與其它 library 的運作也是件不容易的事。
[Pitch] init accessors
Property wrapper 和 SE-0395 Observation 都利用了這些年在高階語言中被證實很實的「加料」功能來實做，以減少模板程式碼以及提供使用者統一的介面，減少預期外的操作方式 －即 stored property 皮 computed proerty 骨。只是要客製初始化這類 property 仍需要寫一個 initializer 並存取真正的變數。
為這類初始化工作提供一個統一的介面，在 computed property 裡加入一個新的 accessor init ，顧名思義，用來提供初始化與該 property 相關的所有工作，像是設值，初始化其它東西 ，乍看之下觸發方式不直覺，因為它仍使用 self.computedProp = someValue的語法，只是這裡的 = 會觸發你在 init 裡的定義，直到所有的的 property 都被 initialize 後它就會指回到 setter。
從 property wrapper 的使用角度很難感受其用途，但若放到一般的 computed property 使用場合就顥得合理，比如下圖。同時這裡也有點出一個新問題，大多時候 set 和 init 會是相同邏輯，這裡將需要一些機制來避免寫重覆的程式碼（比如 init = set），老實說這個提案感覺並沒有真正解決太多痛點，只是有個統一的寫法，而且 `=` 到底是 init 還是 setter 的解讀在大物件裡會變得不容易，再看看未來的討論方向會不會拓展到更多可能性。
🤪 Pofat 選推
Nothing
兩大前端框架強碰啦 （左為 React 核心開發者 Dan，右為 Vue 的尤雨溪）
為賦新詞強說愁 － Microservices
