波報 #23 - Go Hard Or Go Home
Swift 大小事 2002/11/14 - 2022/11/20
💬 Pofat 的話
上週推特依然風風雨雨，雖然應該沒那麼容易就爆炸，還是提醒大家記得備份資料以防萬一。
雖然最近科技業狀況不太好，但 Swift 卻動得很厲害，不少新功能與改善的專案都如火如荼地展開，想貢獻的話現在是開始的好時機！
🌎 On Swift Community
Swift project in 2023
新的一年就要開始，Swift 不但有多元的 Workgroup 往各領域深耕，還有各種專案持續進行中，包括 Build System 與 compiler 更深層地整合、Swift Package 的登錄服務、實作上的改善與新語言功能的開發，比較重要的幾大新功能有：
Concurrency ：當務之急是解決目前的一些複雜使用場合的 thread-safety 漏洞與易用性的改善
Generic：Variadic generic 就是首要任務，只是這將是個為期數年的任務，第一個里程碑是讓 Tuple 有條件地遵循 Protocol。
Ownership：已經在進行中的專案，目的是更安全有效地記憶體管理，接下來將主要打造給開發者的使用介面，包括禁止值隱式地複製 、轉移所有權的功能以及把值「借」給其它人而不是先複製再給。
Macros：可能會是惡夢也可能是天堂的功能
Cpp interoperability： 加強文件與穩定性，其目標之一仍是實現用 Swift 實做 Swift compiler 的可能。
SwiftUI.animation 的不規則行為
動畫在 SwiftUI 中一直令人又愛又恨，因為設計上很簡單就可以實現華麗的效果，但又常常不照你的預期行動。
.animation modifier 會對「目前所在階層的 view」加上動畫，所以其父階層的行為「理論上」不會被套上動畫，也就是接在 .animation 之後的 modifier 其變化都不會帶動畫，但在 Shape 的 .animation 之後如果接了 .foregroundColor ，卻仍然有動畫（如果搞不懂順序與出現動畫與否的關係可以參考這篇文章的說明）。
而 Apple 工程師在上週 Ask Apple 給的答案說明了該案例的原因， 目前只知道有些 modifier 的擺放位置與會否有動畫無關，遺憾的是這些 modifier 並沒有在文件被標註，只能嘗試才知道了（上述文章有列出已知的 modifier）。
Bitcode 並非無用武之地
Xcode 14 拿掉了 bitcode，也一起拿掉了其中對 binary size 的瘦身處理（剪掉用不到的 symbol），所以有不少 app 用 Xcode 14 打包後 ipa 大小爆增（如果本來就沒支援 bitcode 理論上不會有太多影響），如果遇到可以參考 Emerge Tools 的文章處理，本來沒支援的也可以試試看效果，應該有差。
Go Hard Or Go Home
推特員工們本週都收到了一封生死狀，要嘛一起肝出推特 2.0 要嘛被資譴，看起來大多數人最終選擇了回家。
推特會倒嗎？
倒站的消息不脛而走後很多人都在問為什麼，一位資深的 SRE 預想了接下來數週推特可能面臨的危機：
Apple 於酷寒的就業市場中送暖
在接連數波裁員消息與推特的風波之，Apple 不少 team 都在推特上公開招人，我收集了一些，有興趣的讀者們也可以投看看：
Swift Type System!!
SwiftUI Preview!
Apple AR/VR
🗣️ On Swift Forum
[Pitch] Expression macros
Macros in Swift 的表示方式提案，寫起來和 ObjC 時大家所熟的很不一樣，使用時前要要加上 #，比如 let (a, b) = #stringify(1 + 2)；而宣告的方式則是要遵循 ExpressionMacro，很有 Swift 本色的做法。
[Pitch] Reflection
一個提供更高階 reflection api 的 Swift module， Standard library 裡的 Mirror 可以在 runtime 取得物件屬性的名稱與值，通常我們都會選擇把這些資料存入 Dictionary 裡，最主要是因為很難在集合中處理不同屬性的不同型別與值，所以提案建議要有
Type、Field 與 Case 等新型別與相關 API 來讓型別資訊、屬性名稱與 enum 的 case 名稱更方便地被管理使用。
[Pitch] @noImplicitCopy attribute for local variables and function parameters
Swift 一直都幫我們全面管理值語義實例的生命週期，以讓開發者使用起來就像個「值」，但底下如果有 heap object 仍然要靠 ARC 這種昂貴的手段來管理，在對效能斤斤計較的場合，開發者們希望能夠手動管理台面下的行為，目前要做到只能靠 Unsafe 系列的 API，聽起來就很不對勁了，當然大家都不想用。
未來雖有「純移動」型別推出，但那會是一個巨大的 API 變化，於是標記「不複製」便成為控管複製行為的第一步。
@noImplicitCopy 可以標記區域的 let 常數與方法中不是 inout 的參數，編譯器看到就完全不會複製這些物件，只會純粹傳遞它們。
名稱和這個標記與 borrow 的聯合使用情況是提案中最想尋求社群意見的部分。
🤪 Pofat 選推
黑五不知道買什麼可以買 Natalia 出的 SwiftUI in UIKit
自編自導自演
本來不想轉太多推特推但這真的太好笑
這個簡單，放到沒電就好
iPhone 晶片 OIS 實際避震效果影片，好酷
