ハクソク

世界を動かす技術を、日本語で。

スウィフト 6.3

60日前原文(swift.org)

概要

Swift 6.3は、Cとの相互運用性やクロスプラットフォーム開発、組み込み環境への対応を強化。 公式Android SDKの提供により、Android開発にも本格対応。 パッケージ管理やテスト、ドキュメント生成機能も大幅に改善。 新しい属性や最適化制御でAPI設計の自由度向上。 Swiftコミュニティの貢献による進化。

Swift 6.3の主な新機能と改善点

  • Cとの柔軟な相互運用性
    • @c属性 により、Swift関数やenumをCコードに公開可能
    • @c(MyLibrary_callFromC) でC側の宣言名をカスタマイズ
    • @c @implementation の組み合わせで、Cヘッダーで宣言された関数のSwift実装が可能
  • モジュールセレクタ
    • 複数モジュールで同名APIが存在する場合、 ModuleA::getValue() のようにモジュールを明示指定
    • Swift標準モジュール名で Task やString処理APIへアクセス可能
  • ライブラリ最適化制御属性
    • @specialize で汎用APIの特定型向け実装を事前生成
    • @inline(always) でインライン展開を強制（コードサイズ増加に注意）
    • @export(implementation) でABI安定ライブラリの関数実装を公開し最適化範囲を拡大
  • 言語進化提案の詳細
    • 最新の提案一覧は Swift Evolution dashboard 参照

パッケージ・ビルドツール改善

  • Swift Buildのプレビュー統合
    • 全プラットフォーム共通のビルドエンジンをSwift Package Managerに統合
    • クロスプラットフォーム開発体験の一貫性向上
  • Swift Package Managerの新機能
    • swift-syntaxプリビルドバイナリ でマクロライブラリの共通実装を分離
    • 継承ドキュメント制御 でコマンドプラグインのシンボルグラフ生成時のドキュメント継承有無を指定
    • swift package show-traits コマンドでパッケージのサポート特性を可視化
    • 詳細は SwiftPM 6.3 Release Notes 参照

テスト機能の強化

  • Swift Testingの改善
    • Issue.record のseverityパラメータで警告レベル指定
    • Test.cancel() でテストやタスク階層の途中キャンセル
    • 画像添付 （Apple/Windowsプラットフォーム対応）でテスト中に画像を添付可能
    • 採用提案： ST-0012, ST-0013, ST-0014, ST-0015, ST-0016, ST-0017, ST-0020

DocCドキュメント生成の新機能

  • Markdown出力
    • --enable-experimental-markdown-output でMarkdown版ドキュメント生成
  • ページごとの静的HTMLコンテンツ
    • <noscript>タグ にタイトル・説明等を埋め込み、SEO・アクセシビリティ改善
    • --transform-for-static-hosting --experimental-transform-for-static-hosting-with-content で有効化
  • コードブロック注釈
    • nocopy （コピー禁止）、 highlight （特定行ハイライト）、 showLineNumbers （行番号表示）、 wrap （行折返し）などを指定可能
    • --enable-experimental-code-block-annotations で利用開始

プラットフォーム・環境対応

  • 組み込みSwiftの強化
    • C連携、デバッグサポート、リンケージモデルの進化
    • 詳細は Embedded Swift Improvements coming in Swift 6.3 参照
  • Android公式SDKのリリース
    • Swift SDK for Android により、SwiftでAndroidネイティブ開発が可能
    • 既存のKotlin/JavaアプリへのSwift統合もサポート（Swift Java, Swift Java JNI Core）
    • 詳細は Getting Started with the Swift SDK for Android 参照
    • Android Workgroupによる多大な貢献

コミュニティと今後

  • Swift 6.3は Swiftコミュニティ の幅広い貢献による成果
  • 今後の開発や議論は Swift Forums で参加可能
  • Swift 6.3ツールチェーン のインストール方法は Install Swift ページ参照

著者紹介

  • Holly Borla: Swift Core Team/Lang Steering Group所属、Apple Swiftチームのエンジニアリングマネージャー
  • Joe Heck: Apple Open Source Program OfficeでSwift担当

Hackerたちの意見

Swift 6.3には、Android用のSwift SDKの初の公式リリースが含まれてるよ。

└

それはサーバー用のSwiftよりも使われることは少ないだろうね。

└

WindowsやLinuxに似たようなものはあるの？Windowsには5年前のブログ記事があるよ：https://www.swift.org/blog/swift-on-windows/ LinuxにはGNOME用のガイドがあるね：https://www.swift.org/blog/adwaita-swift/ 代わりに一つのスタイルで開発して、OpenSTEPみたいにライブラリのセットを出せたらいいのに（それが「OPEN」って名前の理由だったから）。

Swiftは、ソフトウェアスタックのすべてのレイヤーで使うために設計されてるんだ。確かにいい言語だけど、今の状況じゃそれは実現しないよね。Appleの無駄な機会だな。

└

どういうこと？今のところ、Swiftを使ってソフトウェアスタックのすべてのレイヤーをターゲットにできるよ。例えば、ClearSurgery[0]は完全にSwiftで書かれていて、Linuxボックス上で動いてるリアルタイムコンポーネントも含まれてるんだ。[0] https://clearsurgery.vision

Swift 6.3では、@c属性が導入されて、プロジェクト内のCコードにSwiftの関数や列挙体を公開できるようになったんだ。関数や列挙体に@cを付けると、Swiftが生成するCヘッダーに対応する宣言を含めるようになるから、C/C++ファイルにインクルードできるよ。なんでこんなに時間がかかったんだろう？優先順位が変だよね。Cエクスポートを追加する前に、C++相互運用性のためにC++コンパイラをまるごと追加するなんて。奇妙だな。

└

以前は、アンダースコア付きの属性としてあったよね。

└

C++との相互運用性が注目されたのは、Appleがすでに純粋なCを超えた低レベルのコードベースを吸収できるからだね。Swiftを普通のCにエクスポートするってことは、結局DIYのFFIスパゲッティが増えるだけ。列挙型や所有権のルール、ヌル可否がその境界を越えると、生成されたヘッダーはきれいな橋のようには見えなくなって、ABIバグが隠れる場所が増えちゃう。クロージャーが加わるとさらにややこしくなるから、エラーハンドリングや呼び出し規約が少しずつずれて、午後を無駄にするようなバグが生まれちゃうんだよね。

└

それはしばらく前から実験的な機能としてあったよ。プロジェクトで使ったことがある。

└

もうObjCのエクスポートがあったから、クロスオーバーを考えると優先度は低かったかもね。

Swiftの標準ライブラリの状況は、GoやRustのような新しい言語と比べてどうなのかな？Pythonのようにバッテリーが含まれてるわけじゃないし、macOS/iOSのAPI/ABIにほとんど結びついてるヘルパーライブラリの巨大な開発エコシステムもないよね。

└

利用可能なパッケージの良いソースは、Swift Package Indexだよ。ここでLinuxに対応したパッケージを検索できるよ。[0] https://swiftpackageindex.com/search?query=platform%3Alinux

└

圧縮みたいな基本的なことでもまだ課題があるよね。Githubで怪しくないおもちゃプロジェクトを探す羽目になるし。AppleのCompressionフレームワークですら、ZSTDみたいな重要なアルゴリズムが欠けてる。もう一つの問題は、Apache Software FoundationにSwiftのメンテイナーがいないみたいで、ArrowやParquet用の良い純粋なSwiftライブラリが本当にないんだ。AppleからはSwift CollectionsやSwift Binary Parsingみたいな素晴らしいオープンソースライブラリがいくつかあるけどね。

Swiftで素晴らしいものがどんどん出てきてるのはいいね。でも、v3以降は使ってないんだ。2015年から2017年頃、SwiftはPythonを簡単に dethrone できたはずなんだよね。シンプルで、すごく速くて、C/C++のエコシステムにも簡単に組み込めたから。だから、C++ライブラリを使ってPythonでやってた数値計算のことも、Swiftでできたと思う。サーバーエコシステムも活気づいてきて、IBMもサポートしてたし。やっぱりApple側の失望が大きかったと思う。マーケティングやメッセージングでコミュニティを早く取り込めなかったのが残念。結局、Swiftは主にAppleのエコシステムのものになっちゃって、今やC++の複雑さに追いつこうとしてる。

└

クリス・ラトナーが去ってMojoを作ったのも、あんまり良くなかったかもね。Swift for TensorFlowはその当時、面白いアイデアだったし…。

└

俺もそう思う。Swiftはv3頃はすごくワクワクしてた。小さくて学びやすくて、モダンな感じで、ObjC/C++との相互運用性もバッチリだったのに…。でも、急に複雑さが爆発的に増えちゃった。新しい機能や構文が追加されて、C++みたいに感じる。同じことをするのに10通りの方法があるし。もっとシンプルでスリムな言語にして、追加の複雑さはオプションのパッケージとしてまとめてほしかったな。Swift言語が実際にやってることのほんの一部だけが、言語の一部である必要があるように感じる。

└

ほんとに。GoogleはTensorFlowをPythonからSwiftに切り替えることも考えてたんだよね。https://github.com/tensorflow/swift

└

Swiftは簡単にPythonを dethrone できたかもしれない。個人的にはそう思うけど…いや、違う。私にとって「簡単にできたかもしれない」っていうのは、n-1のことが起こって、1つのことが起こらなかった場合を指す。例えば、ソ連との核交換が「簡単に」起こり得たけど、たった一人のロシア人がもっと証拠を待つことにしたおかげでそれは避けられた。 https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar... でも、2015年から2017年にかけては、Pythonでいろんなことをやってる人が多すぎた（データ指向への大きなシフトは90年代中盤から後半に始まって、MLやPythonの大量使用につながった）からね。その「n」は大きかったし、Swiftに有利な「n」のことはほとんどなかった。もう一度言うけど、個人的な意見ね。

└

2015年から2017年にかけて - Swiftは簡単にPythonを dethrone できたかもしれない。なんでそう思う？ > シンプルで、すごく速くて、C/C++エコシステムに組み込めたから。だから、C++ライブラリを使ってPythonでやってた数値計算のことはSwiftでもできたはず。これに当てはまる言語は半ダースくらいある。 > サーバーエコシステムも活気づいてきて、IBMもサポートしてた。いや、全然違う。KituraやVapor（ぴったりの名前だね）は、真剣なプレイヤーが触れるようなものじゃなかった。

└

Python 3は、なんとかPythonの座を奪っただけだった。

└

C/C++エコシステムに組み込めたから。だから、C++ライブラリを使ってPythonでやってた数値計算のことはSwiftでもできたはず。2015年から2017年にかけてはCと連携できたけど、C++サポートは最近になって追加されたんだよね。でも、君の意見には同意するし、正確な理由は分からないけど、Swiftは確かにAppleのエコシステム言語だね。他のところで traction を得ようとするランダムな努力があっても。

└

Swiftは主にAppleのエコシステムに留まってる。今でも、最新のSwift 6.3を使っても、Appleプラットフォーム以外のアプリにSwiftを使うのはかなり苦痛だよ。それに、信頼の問題もあるし、誰も自分のスタックの一部にAppleの「ゲートキーパー」を自発的に導入するとは思えない。

└

サーバーエコシステムが活気づき始めて、IBMもサポートしてた頃だね。大学生の時で、ちょっとしたフリーランスの仕事をしてお金を稼いでたんだ。クライアントには内緒で、Swiftで彼らのウェブサイトのバックエンドを書いて、Herokuのビルドパックを使ってホスティングしてた。楽しい時期だったし、Swiftは大好きだけど、去年はそのサイトの一つを古き良きTypeScriptに書き直しちゃった。Swiftは好きだけど、Appleのエコシステム以外で使うにはまだ普及してない気がする。

└

v3以降は使ってないけど、5.10からはMacOSなら再び使う価値があるよ。

コンパイル速度の改善については言及がないの？それは残念だね。Rustよりも遅いコンパイル時間は、このまあまあ良い言語の開発体験を妨げちゃうよ。

SwiftでCプログラム用のdylibsを作ったことを覚えてる。確か、実験的な@cdeclアノテーションを使わないといけなかったんだよね。やっと公式になって嬉しい！

nocopyでクリップボードへのコピーを無効にする。これってどう使うの？

スタートアップコストなしでスクリプト用にSwiftを使おうとする試み: Swift Caching Compiler - https://github.com/jrz/tools

SwiftはmacOSとiOS専用で、それ以外のエコシステムではしっかりした使い道がないのが残念だね。でも、他の場所で使われるにはBigTechの力が必要だと思う。

└

SwiftがC#みたいに自由になれることをまだ期待してる。いつかVaporやKituraみたいなものが流行るといいな。