SwiftのString型は、正確さ、パフォーマンス、そして使いやすさの絶妙なバランスを目標にしています。 このトークではString型の背景にある哲学や、私たちがコミュニティとしていかにStringを使ったプログラミングの楽しさと手軽さを追求できるかについてお話しします。
Apple Swift Standard Libraryチームで働いています。
こちらはジッパー
お手伝いしてもらいます
数年前私自身重要な質問を自問自答していました
Stringとはなにか、どのように使っているのか。絵文字、ロケール、Stringは人にコンテンツをプレゼンテーションするために使う
フレームワークの専門家に聞いた。パスなど。
プログラマのDNA、システムに組み込まれているもの
Linux開発者はファイルやテキストストリームの話をしてくれました
学者は、１次元で時空を超えるものだ。
Swiftはこう教えてくれました。
魔法の粉でUnicodeを何かに変換できる
Stringをもっと楽しくしていく
正しさ、最適さ、バランスを保っている
良いAPIは間違った使い方をさせない。
使い勝手は大事、邪魔なAPIを回避できる。一方、パフォーマンスや正確さに損害を与える。
矛盾だらけ
複雑さをこれが追加している。互換性がUnicodeの良いところだが、複雑さがStringに加わってしまっている。
Stringは何で出来ているのか、プログラミング言語に置いては整数の集合。
最近のプログラミング言語はUnicode Scalar値と考える。４つの個別のScalarを見ていく
キャラクタのScalar幅の前提を作っていく。デフォルトでストリングは各長所基礎クラスタ、SwfitではCharacterとよんでいますが、ユーザーが認識する文字とおなじ
良いデフォルトでバグを回避する
Stringのコンテンツを見るところでは、バグを排除することができる、ユーザーのコンテンツの前提を作ることはしない。
どういうキャラクターが必要化について均一な形で見ていく。
Unicodeにおいては物事が不明瞭な場合もある。底でできることはトレードオフを比較評価することしか無い
degenerateというのがある
非直感的な動き、Stringにおいては、degenerateが、
キャラクターの文字数は変わらないが代数的推論に違反する。Swift3ではコレクションを使っていない、それによって使い勝手が悪くなっている。 Unicodeは明示的にdegenerate Graphemeを無視している
実際に使われたら動くことが必要、同バランスを保てば良いのか、理論的に可能と言ってモデルを妥協しない
コレクションにしておくことが必要。
折返しのScalarが真ん中にあることを想定する。
正しい答えはまったくないが、もし確実に正しいと言えない場合にも正しく定義した挙動を持っておく必要がある、ユーザーデータを削除しない、システムセキュリティ苦いのあることをしてはいけない
Stringsの順序について見ていきたいと思います。
ZとO、順番はドイツとスウェーデンで違う
日本語の場合、長母音は前に来る文字に基づいて変わる。コンテキストセンシティブ、内容に基づく。
アルゴリズムに使われる、検索辞書のルックアップに使われる、マシーンが使われる順序付けが必要。
順序付けはバグを排除しなくてはいけない
合成済みのアキュートがついているのはついていないeと同じとみなされる
環境が変わってもオーダーが変わってはいけない
オーダリングと比較は高速でなければならない。
String Key Dictionaryに置いては特に設定する必要がある。
マシンの順序付けは環境で変わってはいけない
一貫した形でプログラミングが整備されなくてはいけない
順序は完全に任意。早いものからということに成る。
パーティーなどで私みたいに人気を博したければNFCのレキソグラフィカルな順序に従う
レキシグラフィカルは人間が従うものではない。
Unicode Scalar Viewにマップする、意味論的にはこちらのほうが正しい、正しいViewを選んでください。
Swift3がはじめてソース安定しました、４ではコレクションがストリング向けに準拠、使いやすく、複数行の文字リテラルも導入されました。OSSコミュニティが作った機能です。重要なパフォーマンス改善がありました。メモリが削減されスモールストリングが表示でき比較も早くなりました。
Swift５でキャラクタプロパティ、rawStringリテラル、カスタムストリングインターポレーションなどがサポート
Lowレベル改善
今までのところでStringの哲学、歴史を話しました。
次のStringのフェーズを紹介します。今後、StringはどこにProduceを設定すべきか、パフォーマンス改善も期待できるでしょう。使いやすさにフォーカスを当てるべきだと思います。
人間工学
正規表現、パーシング、修正、一般的に必要な機能
OSSSwiftの強みはいろいろな見解がコミュニティから投げられる。
ご自身の経験を是非共有してください、現実に即したユースケースを見るほど、コミュニティとして...
実際のコードなど、それに寄ってモチベーションが上がりコミュニケーションがな何か作ることに寄与する
フォーラムに行ってみてください、Swiftカテゴリはビギナーに優しいところになると思います
まとめます。
新しいカスタムの補完を導入してよりクリーンなコードを書けるようにしました。StandardLibraryとして利便性が高くなるでしょう。
Stringを自分自身のインターポレーションの中でやる。１６進法で数字を保管するのはしょっちゅうやっている
Swift5では自分でカスタムインターポレーションに指定できる
マッピングされてコードがわかりやすく。
最後のResultがずれている、最低で幅４で無くてはいけない。
特定Stringでパディングを行っていきます
どれだけ埋めなくてはいけないのか、左側をインターぽレートしていきます。
うまくいきました
ぜひ独自のコードに当てはめて試してみてください
表現性や安全性を型に対して見つけられるようになります。
利便性が高いと思ったものはもしかしたらStandardLibraryの一部に成るかもしれません。
いろいろな方に参加してもらいたいと思います。
OSSSwiftワークショップ、明日やります。お会いできるのを楽しみにしています。
