Rust and Swift（3番目、4番目、5番目、6番目の部分）

著者がRustとSwiftを並行して研究し、それらを互いに比較するサイクルを翻訳し続けます。 イントロダクションと最初の2つのパートの翻訳は、 ここにあります 。 このパートでは、演算子のオーバーロード、文字列操作、およびコレクションに焦点を当てます。

演算子、その過負荷および簡潔さの考え

Swiftのオペレーターに連絡しました。 最初の質問：演算子は特別な構文ですか、それともプロトコルの砂糖ですか？ 私が使用している、またはこれまでに使用したすべての現代言語（Python、Ruby、Io、Elixir、Rust-さまざまな時代とスタイルのいくつかの例）は、他の言語構成の砂糖として単純に実装しています。

整理してみると、演算子は（十分に）定義された関数であることがわかりました グローバルスペース Swiftモジュール。 説明がこれであるため、「良い」の代わりに「大丈夫」と言います。これは、既存の型の間で演算子をバイナリ演算子のように動作させる唯一の方法です。 この場合、理由は言語の構造にあるという事実を見逃しています。 プロトコルはここに完全に収まるように見えますが、おそらく、Rustの特徴とは異なり、問題に十分に対処できないでしょうか？ これは未解決の質問であり、どのように答えればよいかわかりません。

興味深いことに、Rustのオペレーターの数は、前の投稿で言及したものを除いても、Swiftよりもわずかに少ないです。 RustはPythonと同様に、他のより簡単な方法で同じ結果を得ることができるため、プレフィックス演算子とポストフィックス演算子を完全に欠いています。 Swiftでは、これらのステートメントは部分的に保存されています。間違いなく、（Objective）Cを扱ったほとんどのプログラマーはそれらとそのイディオムに精通しているからです。
翻訳者のメモ：Swift 2.2では、元々Rustになかったインクリメント/デクリメント演算子が削除されました。 一方、Swiftでは、独自のステートメントを作成できます。

また、Rustの演算子について何か新しいことを学びました。ブール演算子|| および&&はビットとは異なります| and演算子は、最初のグループが短いスキームに従って計算を実装するという事実だけでなく、 もちろん、2番目のグループの助けを借りて、ビット操作を実行することもできますが、マニュアルでは計算方式の違いを強調しています。 これは完全に正当化されますが、私はそれについて前に考えたことがありませんでした。
翻訳者注：正直なところ、私は著者が何を言いたかったのか理解できませんでした。

Rustには、3項演算子がありません。これは、言語が式とステートメントを処理する方法に関連しています。 Swiftではそうです。 言語設計の違いに関する興味深い考え： ifブロックは式であり、したがって冗長であり、言語の作成者は不要な機能を削除しようとしたため、Rustはこの演算子を削除しました。 （三項演算子の放棄に関する議論と、Brendan Ikeからの興味深いJavaScriptのメモはこちらをご覧ください ）。 私はこれがSwiftに対する批判ではなく、単なる発言であることに留保しますが、式を使用したRustのアプローチは本当に好きです。

一方、私は本当に演算子が好きではありません?? （合体演算子なし）。 収縮のために収縮のように見えますが、一部はオプションの型の簡潔さを求めるSwiftの欲求によるものです。 簡潔にすると、明瞭さが失われることがあります。 過度の略語は言語を複雑にし、各行を読むときに速度を落とすことを強制します。

比較された言語のブール演算子にも違いはなく、驚くことでもありません。

Swiftに関する本で「短い」という言葉またはその同義語が何回使われているのだろうか。 簡潔さがこの言語の主な目標の1つであることをより明確に理解しています。 たぶんそれはそのように思えますが、それでも少し奇妙です。 簡潔さは良いですが、読みやすさははるかに優れています。

文字列操作を使用した言語構造のトレードオフ

SwiftとRustは、セキュリティとメモリ管理の問題を解決しますが、アプローチは異なります。自動参照カウントによるSwiftと、所有権の概念によるRustです。 毎日の作業では、SwiftアプローチはPythonやRubyと同じ理由でより有利に思えます。誰もがあなたのためにそれを行うと便利です。 Rustは多くの機会を提供しますが、同時に所有権について常に考えさせます。

つまり、すべての言語にトレードオフがあります。 私はこれまでSwiftよりRustの方が好きですが、Swiftをより良くする多くのポイントを見つけることは間違いないでしょう。 すべてを手に入れることはできません。

文字列（または値によって渡される他の型）の操作は、RustよりもSwiftの方がはるかに簡単であるため、このことに注意を向けました。 結果は実質的に同じですが、Swiftではすべての行が値によって渡され、参照によって渡されることはないため、変更される内容について考える必要はありません。

もちろん、この目的のためにRustにはコピー特性があります-私は、Swiftが少し「人間工学的」であることを意味します。

Swiftの文字列補間は非常に便利です。 これがRustで見逃している唯一のものです。 文字列をフォーマットするためのPythonスタイルのマクロは優れていますが、値（ strings with \(variables)またはembedded expressions like \(2 + 4) strings with \(variables)補間は非常に優れています。

一般に、文字列に対するSwiftのアプローチはよく考えられており、詳細に十分な注意を払っています。これにより、複雑な言語または非西洋言語での作業が大幅に促進されます。 私は、印刷に夢中なので、本当に感謝しています。

同時に、Swift文字列はUnicodeの同様の境界ケースをすべて処理するため、文字列にアクセスするためのいくつかの標準パターンが失われ、文字列の内部構造を理解することが困難（または不可能）になります。 状況に応じて、これは利点と欠点の両方になります。 私が言ったように、妥協はどこにでもあります。

実際、さらに読み進めてみると、SwiftはUnicode文字列を非常にエレガントに処理し、さまざまな実装に個別のメソッドを使用してプロセスを理解できることがわかりました。 特に、 String型を操作し、「コードポイント」への直接アクセスを取得できることを感謝します。いずれかではなく、UTF8、UTF16、またはUTF32のいずれかにアクセスできます。 Appleの経験を信頼してください。テキストに非常に注意する必要があります。

Rustの文字列は悪くありませんが、それほど複雑ではありません（おそらく、これはメモリ内の文字列の表現を単純化するために行われたと思われます）。 この言語では、 Stringまたはstr常にUTF8バイトのシーケンスとしてエンコードされたスカラーUnicode値（UTF32）で構成されます。 Swiftとは異なり、他の実装を取得するための便利な方法はありません。 同時に、日常のプログラミングでは、これはめったに発生しないか、おそらくまったく発生しないと考えています。 重要なことは、両方の言語がスカラー値を格納することです。

これは、RustのSwiftに対する明確な優位性を感じなかった最初の部分です。 これらの言語の構造におけるトレードオフのいくつかはここでより明確になり、Swiftの「人間工学」がそれらの中にあることを感謝しています。

並列言語学習の利点（および問題点）

私は数週間Swiftを勉強していましたが、その前に1か月間Rustの深みに飛び込みました。 このアプローチ-2つの言語をほぼ同時に学習する-は私にとってまったく新しいものであり、それには十分な理由があります。 プログラミング言語を習得するのは簡単ではありません。新しい知識を理解するには、多くのことを学ぶ必要があります。

これは必要に応じて行います。 Rust言語の非常に機能的で効率的なクロスプラットフォームベースでアプリケーションを開発できることを願っていますが、OS Xのネイティブアプリケーションは、完成したときにのみリリースする予定です。 アプリケーションコアをポータブルにしたいという私の願いは、すぐにSwiftの使用を排除します。 正直なところ、これはAppleの言語であるという事実によっても促進されます。私は彼らのプラットフォームでAppleツールを使うことを楽しんでいますが、この会社の決定に常に依存したくありません。 さらに、Rustの経験は他の多くの場合に役立ちます。

だから、私は両方の言語を学ぶ必要があります。

そして、通常の状況ではお勧めしませんが、まだいくつかの言語の十分なプログラミング経験と知​​識がない場合は、そのような方法の使用を公然と思いとどまらせます-それは信じられないほど有用であるように思えます。 これらの言語はほぼ同時に作成され、同じソースからインスピレーションを引き出しました。対象者と目標は部分的に重複しています。 同時に、このシリーズで既に示したように、多くの点でかなり異なります。

2つの言語を並行して研究することで、それぞれの言語が妥協したものを確認し、それらの違いの原因を考えることができました。 特に、私はこれらの言語の舞台裏で何が起こっているかをよりよく理解し、それらに何を期待するかを知っていると思います。 これは、言語の学習速度に大きな影響を与えました。 もちろん、ここで私はいくつかの言語を知っており、最近視野を広げたという事実にも役割を果たしました。Haskell、JavaScriptの機能パターンなどについて読みました。

もちろん、両方の言語で私はまだ長い道のりを持っています。 夜や週末に本を読んだり、それぞれで少し遊んだりすることは、歯でプロジェクトに固執して痛みを感じることと同じではありません。 しかし、これらの言語を同時に学んでいることは本当にうれしいです。 チャレンジを受け入れる準備ができている場合は、試すこともできます。 どれだけ学ぶことができるかに驚くでしょう。

コレクションのタイプと、構文とセマンティクスの区別

次の文は、Swiftの言語設計を多くの点で特徴づけていると思います。

2つの形式は機能的には同じですが、より短い形式が推奨され、このマニュアルではデータ配列のタイプを参照するために使用されます。 —Swiftプログラミング言語（Swift 2プレリリース）

Rust std::collectionsモジュールのさまざまなタイプのドキュメントは、興味深く有用です。 強くお勧めします。

Swiftマニュアルのこの章を読んでいると、Rustには名前付きパラメーターはありませんが、Swiftにはあります。 どちらの場合も、この決定は合理的ですが、これはRustでほとんど自慢しない詳細の1つであるように思われます。 Pythonは私を甘やかしました。
翻訳者注：名前付きパラメーターをRustに追加するためのRFCがあります。

SwiftのArray型は、RustのVec型（通常はvec！マクロによって作成されます）に似ています。 Rustの配列は静的なサイズを持ち、スタック上に作成されますが、両方のコンテナーはヒープ上の要素を動的にサイズ変更および格納できます。 両方の言語で配列を作成する構文は非常に似ています（ただし、結果は異なります）。

 let an_array: [Int] = [1, 2, 3] //    var an_array = [1, 2, 3] //    

 let an_array: [i32, 3] = [1, 2, 3]; //  let a_vector: Vec<i32> = vec![1, 2, 3]; //  

どちらの言語でも入力できるため、これは短く書くことができます。そのため、そのように書く必要はほとんどありません。 より馴染みのあるオプションは次のとおりです。

 let an_array = [1, 2, 3] var an_array = [1, 2, 3] 

 let an_array = [1, 2, 3]; let a_vector = vec![1, 2, 3]; 

Rustは、配列の一部へのアクセスを提供し、配列へのポインタとサイズ（要素の数）を表す「スライス」の概念も追加します。

Swiftの配列操作は非常に論理的で、驚くほど視覚的です。 それらは良い意味で、Pythonでのリスト操作を思い出させます。

RustのVecコンテナーには豊富なAPIがあり、それは悪くありません。 要素をトラバースするメソッドがないことに少し驚きましたが、Iteratorトレイトが実装された同じモジュールのIntoIter構造に存在することがわかりました。 その結果、対応するメソッドはEnumerate構造体のインスタンスを返します。 （Swiftの配列はIterableプロトコルを実装しているだけで、これはRustのアプローチにいくらか似ているとIterableます。）

これは私がよく話していることの例です。Rustは必ずしもすべてを1つのオブジェクトに入れるのではなく、いくつかの関連する構造、関連付け、または特性に機能を分散します。 これは本当に強力なアプローチですが、多少の習慣が必要です。 この点で、Swiftの構造とセマンティクスは、私が慣れている言語に非常に似ていますが、プロトコルを使用すると柔軟性が高まります。

構文ではなくセマンティクスについて話していたことに注意してください。 SwiftとRustは、非常に類似した構文がセマンティクスの違いをどのように隠すことができるかを示す素晴らしい例です。 別の例：JavaScriptとJavaの構文とセマンティクスを比較します-一見、構文は似ていますが、セマンティクスには大きなギャップがあります。

SwiftのSetと、RustのHashSetに対応するHashSet対応の両方に、Pythonのinキーワードに非常に類似したcontainsメソッドがあります。 両方のタイプが同じメソッドの多くを実装していることは驚くことではありません。 セットが標準的な数学的概念であるという事実を考えると、おそらくこれは予想されるべきです。

タイピングがより厳密なため、RustとSwiftの両方で、連想配列（RustのHashMapとSwiftのDictionary ）で使用される型を指定する必要がありますが、もちろん両方の言語は特定の場合に型を出力できます。 Pythonで許可されているように異なる種類のキーの使用を混在させることはできませんが、実際には、これは2つの理由で気にしないはずです。

1. 原則として、異なるタイプのキーを使用することは推奨されません。 私の場合、これは多くの場合、使用するタイプとデータ構造について慎重に検討する必要があることを示しています。
2. まれに、必要に応じて、RustまたはSwiftでジェネリック型を使用できるかどうか疑問に思っています。 この問題は後で明らかにする予定です！

SwiftがPythonのような構文（ {'': ''} ）を使用して連想配列を初期化するのは素晴らしいことです。 しかし、なぜこれが不可能なのか理解しています：中括弧はすでにブロックで占められていますが、Pythonではインデントを使用するため、そのような問題はありません。 しかし、それは本当に便利です。

Swiftデザイナーが括弧（ [...] ）を使用してシーケンスを初期化した理由を理解しています。これにより、解析が大幅に簡素化されます。 その結果、一見すると、あなたが何を扱っているのか理解するのは困難です。 配列、セット、または連想配列にすることができます。

これは、プログラミング言語の設計の過小評価されている側面-可読性を強調しています。 プログラマがコードを書きたくないのと同じくらい、実際には、ほとんどの場合、それを読むのに多くの時間を費やしています。 したがって、記述の容易さに注意を払う必要がありますが、コードの読みやすさについても考える価値があります。 言語で採用されている構文と規則は、この大部分を形成します。

SwiftのDictionary型は、いくつかのメソッドの名前が一致するまで、PythonのDictionary型に非常に似ています。 これは、RustのHashMapにも当てはまります。 これはまったく悪くありません。

翻訳者からのあとがき

この一連の記事の翻訳を行うのは良い考えだと疑い始めます。 著者には、Swiftについてさらに学ぶように促した興味深い考えがあります。 一方、彼は表面的な判断が多すぎるため、自分で情報を検索する必要があります。 私が定期的にやろうとしているように、あなたがメモで翻訳を補うなら、それらはほとんど各アイテムに書かれなければならないでしょう。 最終結果は翻訳ではありませんが、悪魔は何を知っています。 だから私はおそらくこれらの部分にこだわるでしょう。