🖱️ 🗾 🙋🏽 Rustでコードを再利用する多くの方法 🧑🏽‍🤝‍🧑🏼 🚴🏿 ☕️

Alexis Beingessner によるこの記事は、Rustの型システムの最も包括的な説明であり、それを使って何ができるかを見つけました。 誰かがこの翻訳が役立つと思うことを願っています。 明らかなことが最初に記述されているという事実を見ないでください-あなたは最後にdrれます。 この記事は巨大であり、ほとんどの場合章に分かれています。 非常に自由に翻訳されました。 著者のスタイルが保存されました。 -約

（Rust 1.7安定版について書かれた記事）

Rust型システムには、やるべきことがたくさんあります。私の知る限り、これのほとんどすべての複雑さは、プログラムを最も一般的な方法で表現することです。さらに、人々はまだ多くを必要とします！この投稿は自分自身を思い出させる可能性が高いので、私は常に最も複雑なことを簡単に理解するのに問題がありました。それにもかかわらず、私は他の人にとって有益なこともしたいので、この記事には忘れることはないが、一部は知らないこともあります。

この記事では、構文の包括的な説明や、説明されている機能の一般的な詳細については説明しません。私はいつもそのようなことを忘れているので、 なぜこれが何らかの形で起こっているのかを説明します。 Rustを完全に学習しようとしてこの記事を見つけた場合は、必ず本を読むことから始めてください（オリジナルはここにあります -約Per。）。同時に、私はここで何が起こっているかのarbitrary意的な理論的側面をいくつか明らかにします。

ほとんどの場合、この記事はエラーでいっぱいであり、公式のリーダーシップを装うべきではありません。これは、新しい仕事を探していたときに1週間で掘り出したもののコレクションです。

コード再利用原則の概要

（以降、「再利用」とは「再利用」を意味します-それほど厄介な音ではなく、より早く理解されます-約per。）

コードの一部を複数回使用したいという要望は、最初のコンピューターが最初の有用な結果ビットを取得した最初の頃から存在していました。確かに、コードを再利用することでその素晴らしい時期がどのように見えたのか、私にはわかりません。たぶん、ベビーベッドの葉？またはパンチカードの山？わからない。私はこれが今どのように行われるかにもっと興味があります。

最もよく知られているコードの再利用形式は、断然関数です。ええ、はい、機能は誰もが知っています。ただし、作成している言語と実行する必要がある内容によっては、コードの再利用を受け取るなどの機能の機能が十分でない場合があります。おそらく、「メタプログラミング」（コードがそれ自体を作成するとき）または「ポリモーフィズム」（コードをさまざまなタイプのデータに適用できるとき）という現代用語の下に存在する何かを適用する必要があります。

技術的には、これらの原則は完全に異なりますが、しばしば一緒に使用する必要があります。現代の言語では、マクロ、テンプレート、ジェネリック、継承、関数へのポインター、インターフェイス、オーバーロード、グループ化（ユニオン）など、これらの原則の実装は非常に広く表現されています。ただし、これはすべて、3つの基本原則（単相性、仮想化、列挙）の実装の意味的な多様性にすぎません。

単相

単相性とは、基本的にコードのコピーと貼り付けの練習であり、新しいコピーごとに小さな変更が加えられます。単相性の主な利点は、複雑な構造でコンパイラを怖がらせることなく、実装を「完全にカスタマイズ」できることです。これも原則の主な欠点です-最悪の場合、使用されるすべての場所に物理的にコピーされる多くのほぼ同一の部分のために、かなり太いコードを取得します。シックバイナリとコンパイル時間の増加に加えて、プロセッサの命令キャッシュへの膨大な負荷がここに追加されます。実際、ここでコードを再利用する臭いはありません！

単相性の意味上の制限は、複数の異なるデータ型を同時に処理する際に（直接）使用できないことです。たとえば、さまざまなタスクを受け入れるジョブキューを作成し、それを使用してこれらのタスクを受信順に完了させたいとします。すべてのタスクが同一であれば、すべてが単相によって簡単に解決されます。タスクが異なると問題が発生します。これを単相性だけで実装する方法が不明確になります。したがって、彼の名前は単射です。 1つだけのことを行うコードの抽象化。

単相性の一般的な例：C ++テンプレート、Cマクロ、Go Generate、C＃ジェネリック。それらのほとんどはコンパイル時に機能しますが、C＃ジェネリックを除き、実行時にモノモーフになります。コンパイル中に作成されるものはすべてテンプレートです。単相性は、従来の（インライン）およびJITコンパイルを使用した最適化の手段として非常に人気があります。

仮想化

すべての開発者がやってくる、コピー・アンド・ペーストに十分な役割を果たした単相性の正反対：アプリケーションの多様性を引き締めます。データと実行可能コードの両方を仮想化することができます。その後、仮想インターフェイスのユーザーが見るものはすべて、 何かを指すものになります。

仮想化により、コードはサイズや構造が異なるタイプでもまったく同じように機能します。関数の仮想化により、コピーと貼り付けを行わずに代替の動作を実現できます。単相性が歯を壊す実行キューの例は、仮想化によって完全に解決されます。実行する必要があるタスクは、検出および起動できる機能へのポインターです。タスクごとに個別にデータが必要です-質問なし、データに別のポインターを追加すると、関数にロードされます。

仮想化の主な欠点は、 通常、パフォーマンスに影響すること、コードの変動性がヒープ上のメモリの頻繁な割り当てに変換されること、ポインターのジャンプ（キャッシュがdしていること）、および現在何を処理しているかを正確に決定することです。

ただし、仮想化は単相化よりも生産的です！関数が静的にジャークするたびに、コンパイラーはそれをインライン化できますが、既に述べたように、バイナリーをオーバーロードしてリターするため、常にこれを行うとは限りません。同じ理由で、めったに使用されない機能を強制的に仮想化することは有益です。たとえば、例外ハンドラは常に実行する必要はないため、例外ハンドラを仮想化して、「エラーのない」実行ブランチの命令キャッシュをクリアすることをお勧めします。

一般的な仮想化の例：Cの関数ポインターとvoidポインター、コールバック、継承、Javaジェネリック、Javascriptプロトタイプ。これらの例の多くでは、データ仮想化と実行可能コードの間に違いはないことに注意してください。たとえば、動物へのポインタがある場合、猫と犬の両方がその後ろに立つことができ、この動物に投票を依頼するとき（） -彼はどこかから知っている、「ウーフ」または「ニャー」を教えてください。

各タイプの各オブジェクトに仮想化を実装する通常の方法は、「vtable」と呼ばれるプログラムの動作中に必要になる可能性のあるさまざまな実装へのポインタの隠されたストレージの継承の階層です。通常、vtableには関数（上記の例のvoice（）を含む）への一連のポインターが格納されますが、特定のタイプのオブジェクトのサイズ、メモリ内のアライメントも可能です。

乗り換え

列挙型は、仮想化と単相性のトレードオフです。実行時には、 オプションなしの単相コードは1つだけで 、virtualizedは何でもかまいません。リストからのコードはオプションの限られたリストのどれでもありえます。通常、列挙の使用は、使用するリストのオプションを定義する整数の「タグ」を操作することです。

たとえば、列挙によって実装される実行キューは、「作成」、「変更」、「削除」の3つのタイプの可能なタスクを定義できます。たとえば、「作成」を使用するには、「作成」機能に対応するタグでマークされた作成用のデータをキューに送信するだけです。キューはタグを認識し、タグから何が欲しいのか、データに何があるのかを理解し、対応するコードを実行します。

仮想化と同様に、列挙は同じコードを使用してさまざまなタイプのデータを理解できますが、コピーする必要はありません。単相性のように、可変性の必要はありません-タグのみが変更されます。さらに、転送の最適化ははるかに簡単です。

ただし、可変性がまったく使用されない場合、列挙型は深刻に成長することに注意する必要があります。これは、各型オブジェクトが列挙内の最大型の情報を格納する必要があるためです。「削除」するには、名前だけで十分ですが、「作成」は名前、タイプ、作成者、コンテンツなどを要求します。キューが主に「削除」に使用される場合でも、メモリになります。永続的な「作成」の両方を要求します。

もちろん、機能の全範囲を事前に知る必要があります。これが転送の主な制限です。単相性と仮想化の両方を必要に応じていつでも拡張できますが、列挙については言えません-テンプレートを新しい型に重ねることができ、クラスを継承でき、列挙は既にコードでしっかりと焼き付けられています。欺いて拡大しようとする試みでそれを選ばない方が良いです-あなたはすでにそれを使用している人のコードを破る可能性が高くなります！

したがって、この戦略は部分的に理解不能です。多くの言語はenumの形式でそれを持っていますが、列挙内のオプションごとに個別にデータを関連付けることができないため、その使用は非常に制限されています。 Cでは、オプションを2つのタイプのグループとして定義できますが、問題の解決策は、これらのタイプのデータと、列挙のユーザーに課されるコードです。多くの関数型言語には、タグのあるグループ（タグ付きユニオン）があります。これは列挙のユニオンであり、Cのグループにより、任意のデータを異なる列挙オプションに固定できます。

Rustはどうですか？

ええ、はい、他の言語の可能性をリストしましたが、私たちの言語で何ができますか？そして、私たちのものではすべてが3つの柱にかかっています：

マクロ（単純な単相）
列挙（完全、データあり！）
特徴（ここでは楽しいでしょう）

マクロ

ここではすべてが簡単です。コードのネット再利用。 Rustでは、メイン構文ツリー（AST、抽象構文ツリー）の最上部で機能します。マクロを構文ツリーにフィードすると、結果は別のツリーになります。「うーん、この行は誰かの名前に似ています」などのタイプに関する情報は、マクロにはありません（実際には少しあります -約あたり）。

通常、マクロは2つの理由で使用されます。言語自体を拡張するか、既存のコードのコピーを作成します。最初のものは、Rust標準ライブラリの一部の場所で公然と使用されています（ println！、 Thread_local！、 Vec！、 Try ! 、その他すべて）：

///   `Vec`,  . /// /// `vec!`   `Vec`s    . ///     : /// /// -  `Vec`    : /// /// ``` /// let v = vec![1, 2, 3]; /// assert_eq!(v[0], 1); /// assert_eq!(v[1], 2); /// assert_eq!(v[2], 3); /// ``` /// /// -  `Vec`      : /// /// ``` /// let v = vec![1; 3]; /// assert_eq!(v, [1, 1, 1]); /// ``` /// ///   -          , ///    `Clone`,      ,    . /// ///   `clone()`   ,    ///     `Clone`. , /// `vec![Rc::new(1); 5]`         integer  , ///     . #[cfg(not(test))] #[macro_export] #[stable(feature = "rust1", since = "1.0.0")] macro_rules! vec { ($elem:expr; $n:expr) => ( $crate::vec::from_elem($elem, $n) ); ($($x:expr),*) => ( <[_]>::into_vec($crate::boxed::Box::new([$($x),*])) ); ($($x:expr,)*) => (vec![$($x),*]) }

後者は、多くの反復的なインターフェースを実装するために内部的に使用されます。

 //        //  T -> T      . //          //      macro_rules! impl_from { ($Small: ty, $Large: ty) => { impl From<$Small> for $Large { fn from(small: $Small) -> $Large { small as $Large } } } } //  ->  impl_from! { u8, u16 } impl_from! { u8, u32 } impl_from! { u8, u64 } //         ...

私の考えでは、マクロはコードを再利用する最悪の方法です。彼らは何らかの形で役立つはずです（変数名は内部で使用されておらず、マクロからリークしません）が、それらを好む人がたくさんいます（マクロで安全でないものを使用すると、奇妙な副作用が発生します（どうでしょう？-約トランス））。マクロハンドラーは正規表現に基づいており（ exprとttの 解析が些細なことではないという事実に目を閉じた場合）、一般的に、誰も正規表現を読むのが好きではありません！

さらに重要なことは、ここでのマクロは、本質的に動的型付けによるメタプログラミングであるということです。コンパイラーは、マクロ本体がその署名と一致することをチェックせず、マクロに従ってコードを生成し、出力で何かを受け取り、その後チェックするだけで、典型的な動的プログラミングの問題-遅延エラーバインディングにつながります。したがって、Rustの「不定」は「不定」は関数ではありません 。

 macro_rules! make_struct { (name: ident) => { struct name { field: u32, } } } make_struct! { Foo }

 <anon>:10:16: 10:19 error: no rules expected the token `Foo` <anon>:10 make_struct! { Foo } ^~~ playpen: application terminated with error code 101

この間違いは何ですか？もちろん、マクロは名前を変数として理解せず、リテラルとして認識し、常に返すため、 $を忘れました

 struct name { field: u32 }

（正直なところ、マクロをクールに扱う理由は-あたりあたりです。）

さらに、マクロによって生成されたコードで定期的なエラーが発生した場合、ログに消化できない混乱があります。

 use std::fs::File; fn main() { let x = try!(File::open("Hello")); }

 <std macros>:5:8: 6:42 error: mismatched types: expected `()`, found `core::result::Result<_, _>` (expected (), found enum `core::result::Result`) [E0308] <std macros>:5 return $ crate:: result:: Result:: Err ( <std macros>:6 $ crate:: convert:: From:: from ( err ) ) } } ) <anon>:4:13: 4:38 note: in this expansion of try! (defined in <std macros>) <std macros>:5:8: 6:42 help: see the detailed explanation for E0308

ええと...しかし、他の動的に型付けされた言語のように、私たちのプラスでは、式の柔軟性が大幅に向上しています。要するに、マクロは、その使用が正当化される領域で美しく、単に...壊れやすい、または何かです。

言及する価値がある：構文拡張とコード生成

もちろん、マクロには制限があります。コンパイル時に任意のコードを実行しません。これはセキュリティと頻繁なアセンブリには適していますが、邪魔になることもあります。 Rustでは、これを2つの方法で修正できます：構文拡張（ 手続き型マクロ ）とコード生成（build.rs）（不安定な言語ブランチにはまだコンパイラプラグインがあります -およそ）。それらはすべて、何かを生成するために何かをするための青信号を与えます。

構文拡張はマクロまたは注釈のように見えますが、コンパイラに任意のアクションを実行して構文ツリーを（理想的には）変更するように依頼する機能があります。 build.rsファイルは、パッケージをビルドするたびにビルドおよび実行する必要があるものとしてCargoパッケージマネージャーに認識されます。明らかに、彼らは喜んでプロジェクトに群がることができます。アクセスできないマクロ生成コードにはこれを使用する方が良いと予想されます。

いくつかの例を追加することもできますが、特にこれらの機会についてはそうではなく、私はそれらにまったく無関心です。まあコード生成、大丈夫。そして一般的に、私は数日間この記事を書いていて、 徹底的に立ち往生しています （著者キャップは削除されました-約Per。）。

乗り換え

前述のタグを使用した正確なグループ化。

OptionとResultに直面して最もよく見られ、何かの成功/失敗の結果を表します。つまり、これらは文字通り「成功」と「ブレークダウン」オプションの列挙です。

あなた自身の転送を書くことができます。ここでは、たとえば、 ipv4およびipv6で動作するネットワークコードが必要です。仮にipv8をサポートする必要は絶対にありません。たとえそれが必要であっても、犬はコードでそれをどうするかをまだ知っています。私たちは正確に何のための列挙を書いています：

 enum IpAddress { V4(IPv4Address), V6(Ipv6Address), } fn connect(addr: IpAddress) { // ,  ,    match addr { V4(ip) => connect_v4(ip), V6(ip) => connect_v6(ip), } }

それだけですさらに、一般的なタイプのIpAddressを操作できます。また、内部の正確なタイプを知る必要がある場合は、 matchを使用して上記の方法を使用してフィッシングアウトできます。

特性

ここまでは、すべてがシンプルでしたが、今ではより複雑で興味深いものになります。

要するに、Rustの特性は、 他のすべてを記述するように設計されています 。単相化、仮想化、リフレクション、演算子のオーバーロード、型変換、コピーのセマンティクス、スレッドセーフティ、高次関数、ループのイテレーター-このカラフルなパノプティコンはすべて特性を介して機能します。さらに、すべての新しいユーザー言語機能は、ほとんどの場合、特性を通じて実装されます。

一般的に、特性はインターフェースです。いいえ、本当に。

 struct MyType { data: u32, } // ,   trait MyTrait { fn foo(&self) -> u32; } //     impl MyTrait for MyType { fn foo(&self) -> u32 { self.data } } fn main() { let mine = MyType { data: 0 }; println!("{}", mine.foo()); }

多くの場合、特性との通信はJavaまたはC＃のインターフェースとの通信と違いはありませんが、場合によっては境界線を越える必要があります。特性は、アーキテクチャ的に柔軟に設計されています。 C＃およびJavaでは、 MyTypeの所有者のみがMyTypeにMyTraitを実装できます。 Rustでは、 これは MyTrait の所有者にも許可されています。これにより、特性ライブラリの作成者は、標準ライブラリの型などに対しても実装を記述できます。

確かに、このような機能をそのまま使用するのは非常に困難です。誰もがそれを販売するには不十分です。したがって、この幸福は、スコープ内に対応する特性を持つコードの実装の可視性によって制限されます。したがって、ちなみに、 読み取りと書き込みを明示的にインポートしないと、I / Oの操作に関するすべての問題が発生します。

トピック：一貫性

Haskellに精通している人は、型クラスと共通する特徴を多く見ることができます。彼らには完全に明白で正当な質問をする権利があります。実際、同じタイプの同じ特性を異なる場所で数回実装するとどうなりますか？一貫性の問題、つまり。一貫した世界では、特性タイプの実装は1ペアのみです。また、Rustでは、一貫性を実現するために、Haskellよりも多くの制限があります。制限は次のとおりです-あなたは、特性、またはそれを実装する型のいずれかの所有者でなければなりません。また、循環依存関係があってはなりません。

 impl Trait for Type

それは美しく、シンプルで理解しやすいですが、次のようなものを描くことができるため、少し間違っています：

 impl Trait for Box<MyType>

TraitとMyTypeが物理的にどこにあるかわからなくても。このような操作の正しい処理は、一貫性の主な難しさです。それはいわゆるによって規制されています「オーファンルール」では、依存関係のネットワーク全体に対して、特定のタイプの組み合わせに対する特性の実装が1つのクレートのみに含まれるという条件が必要です（組み合わせについては、以下を参照-約。）。その結果、同時にインポートされる、競合する実装を含む2つの異なるライブラリは、単にコンパイルされません。これは時々、ニコ・マタキスが自然に呪われたいと思うほど迷惑です（ニコ・マタキス、Rustの主なコミッターの一人-約あたり）。

おもしろいのは、標準のRustライブラリ（いくつかのばらばらの部分から内部に接着されている）の不整合が非常に一般的であるため、一部の特性、実装、および型が予期せぬ場所にかなり現れることです。型をシャッフルしてもあまり役に立たず、松葉杖＃[基本]になり 、矛盾に目をつぶるようコンパイラーに指示するのはさらに楽しいです。

ジェネリック

（私はそれらを「一般化された型」と呼ぶのが正しいことを理解していますが、これは第一に長い間、そして第二に、彼らはまだ「ジェネリック」という用語を使用しているので、あまり明確ではありません-約）

では、どのように特性を使用してコードを再利用しますか？ここでRustが選択肢を与えてくれます！私たちはモノモーフィングでき、仮想化できます。 ほとんどの場合の単相性は、私が見たほとんどのコードだけでなく、標準ライブラリでも選択できます。これはおそらく、単相性全体がより効率的であり、明らかにより一般化されているためです。それにもかかわらず、単相のインターフェイスは仮想化できます。これについては後で説明します。

単相インターフェースは、ジェネリックによってRustに実装されます。

 //  ,   . struct Concrete { data: u32, } //  . `<..>`     . //    `Generic`   ,  // `Concrete`,         `u32`. struct Generic<T> { data: T, } //   impl Concrete { fn new(data: u32) -> Concrete { Concrete { data: data } } fn is_big(&self) -> bool { self.data > 120 } } //     Foo. // ,   ,   , //        //   . // ( ,         - ..) impl Generic<u32> { fn is_big(&self) -> bool { self.data > 120 } } //     T. // "impl"   Generic. // ,      //  ,     <T>. impl<T> Generic<T> { fn new(data: T) -> Generic<T> { Generic { data: data } } fn get(&self) -> &T { &self.data } } //  . trait Clone { fn clone(&self) -> Self; } //  . //     .      //       ,    . //   . trait Equal<T> { fn equal(&self, other: &T) -> bool; } //    impl Clone for Concrete { fn clone(&self) -> Self { Concrete { data: self.data } } } //        impl Equal<Concrete> for Concrete { fn equal(&self, other: &Concrete) -> bool { self.data == other.data } } // ,      ,    ! impl Clone for u32 { fn clone(&self) -> Self { *self } } impl Equal<u32> for u32 { fn equal(&self, other: &u32) -> Self { *self == *other } } //  ,   ! impl Equal<i32> for u32 { fn equal(&self, other: &i32) -> Self { if *other < 0 { false } else { *self == *other as u32 } } } //        impl<T: Equal<u32>> Equal<T> for Concrete { fn equal(&self, other: &T) -> bool { other.equal(&self.data) } } //        // ,  ,  `T`  //  `Clone`!  * * (trait bound). // (  , .    - ..) impl<T: Clone> Clone for Generic<T> { fn clone(&self) -> Self { Generic { data: self.data.clone() } } } //       . //     - U. impl<T: Equal<U>, U> Equal<Generic<U>> for Generic<T> { fn equal(&self, other: &Generic<U>) -> bool { self.equal(&other.data) } } //  ,     . impl Concrete { fn my_equal<T: Equal<u32>>(&self, other: &T) -> bool { other.equal(&self.data) } } impl<T> Generic<T> { // ,   :   `equal`  , //  ,   . // (`x == y`     `y == x`).       , //   `T: Equal<U>`   ?       //   `T`,   `U`   ! //   . fn my_equal<U: Equal<T>>(&self, other: &Generic<U>) -> bool { other.data.equal(&self.data) } }

ふう。

ご覧のとおり、インターフェイスとその実装を定義する必要が生じたらすぐに、一般性のさまざまなバリエーションに対して幅広い選択肢があります。そして、コンパイラの内部では、私が言ったように、これはすべて単形化します。少なくとも最初の最適化まで、次の中間コードを取得します。

 //  struct Generic<T> { data: T } impl<T> Generic<T> { fn new(data: T) { Generic { data: data } } } fn main() { let thing1 = Generic::new(0u32); let thing2 = Generic::new(0i32); }

 //  struct Generic_u32 { data: u32 } impl Generic_u32 { fn new(data: u32) { Generic { data: data } } } struct Generic_i32 { data: i32 } impl Generic_i32 { fn new(data: i32) { Generic { data: data } } } fn main() { let thing1 = Generic_u32::new(0u32); let thing2 = Generic_i32::new(0i32); }

驚くかもしれませんが（驚くこともありませんが）、いくつかの重要な機能は多くの場所にインライン化されています。たとえば、brsonはServoコードで1700個を超える Option :: mapの コピーを見つけました。一般に、これらすべての呼び出しを仮想化すると、実行時のパフォーマンスが完全に低下します。

また重要：型定義と演算子「ターボフィッシュ」

（「turbofish」をよりうまく翻訳することはできません。オプションは大歓迎です-約。）

Rustのジェネリックは、型を自動的に検出します。タイプがどこかに指定されている場合、すべてが時計のように機能します。指定されていない場合、花火が始まります：

 // Vec::new()  ,     //   ,   .   .     //  `Vec`,  -  . let mut x = Vec::new(); //    `u8`  `x`,    `Vec<T>` x.push(0u8); x.push(10); x.push(20); // `collect`   .   ,   // `FromIterator`,    Vec  VecDeque. //    - ,    // `collect` ,    `Vec::new()`,     //     //  -     . let y: Vec<u8> = x.clone().into_iter().collect(); //    ,       //   "-" `::<>`! let y = x.clone().into_iter().collect::<Vec<u8>>();

特性オブジェクト

それでは、ここで仮想化はどうなっているのでしょうか？単に顔のない「何か」になるために、特定のタイプに関する情報を削除するにはどうすればよいですか？ Rustの場合、これは特性オブジェクトで発生します。この型インスタンスは特性のインスタンスであり、コンパイラが残りを行うと言うだけです。もちろん、インスタンスのサイズも無視する必要があります。これは、＆、＆mut、Box、Rc、Arcなどのポインターの後ろにも隠れているためです。

 trait Print { fn print(&self); } impl Print for i32 { fn print(&self) { println!("{}", self); } } impl Print for i64 { fn print(&self) { println!("{}", self); } } fn main() { //    let x = 0i32; let y = 10i64; x.print(); // 0 y.print(); // 10 // Box<Print> - -,     // ,  Print.   Box<Print>    // `Box<T: Print>`,    -,   `Box<Print>`. //    `data`  `Box<Print>`, //  -     ! // ,    i32  i64     , //         . let data: [Box<Print>; 2] = [Box::new(20i32), Box::new(30i64)]; //     . for val in &data { val.print(); // 20, 30 } }

ポインタの後ろに特定のタイプを非表示にするという要件は、一見思われる以上の結果をもたらすことに注意してください。ここに、例えば、私たちの古いおなじみの特徴があります：

 trait Clone { fn clone(&self) -> Self; }

特性は、 値によって独自のタイプのインスタンスを返す関数を定義します 。

 fn main() { let x: &Clone = ...; // -  ,  let y = x.clone(); //   , ...? }

しかし、 yのためにスタック上にどのくらいのスペースを確保する必要がありますか？彼はどんなタイプですか？

答えは、コンパイル段階ではこれがわからないということです 。これは、 クローンの特性が実際には無意味であることを示唆しています。より正確には、値としての独自の型への参照が含まれている場合（およびポインターではなく、約Per。）、特性を特性オブジェクトに変換することはできません。

特性オブジェクトは、Rustでかなり予想外の方法で実装されます。覚えておいてください-通常、この目的のために仮想化された関数テーブルが使用されます。この方法には、少なくとも2つの理由があります。

まず、必要があるかどうかに関係なく、すべてがポインターの背後に格納されます。つまり、型が仮想化可能として定義されている場合、その型のすべてのインスタンスはこのポインターを格納する必要があります 。

2つ目は、仮想テーブルから必要な関数を取得することです。タスクはそれほど簡単ではありません。これはすべて、インターフェイスが一般に、多重継承の特殊なケースであるという事実によるものです（C ++では、多重継承は完全です）。例として、これらのセットを次に示します。

 trait Animal { } //  trait Feline { } //  trait Pet { } //  // , ,  struct Cat { } // ,  struct Dog { } // ,  struct Tiger { }

Animal + PetやAnimal + Felineなど、混合型の場合に関数ポインターのストレージを整理する方法は？ 動物+ペットは猫と犬で構成されています。サインに従ってそれらをトリミングします。

猫vtable犬vtable Tiger vtable
 + ----------------- + + ----------------- + + ----------- ------ +
 | タイプのもの|  | タイプのもの|  | タイプのもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | 動物のもの|  | 動物のもの|  | 動物のもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | ペットのもの|  | ペットのもの|  | ネコのもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | ネコのもの|
 + ----------------- +

そして今、猫と虎は異なっています。 OK、ペットと猫の猫を入れ替えましょう：

猫vtable犬vtable Tiger vtable
 + ----------------- + + ----------------- + + ----------- ------ +
 | タイプのもの|  | タイプのもの|  | タイプのもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | 動物のもの|  | 動物のもの|  | 動物のもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | ネコのもの|  | ペットのもの|  | ネコのもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | ペットのもの|
 + ----------------- +

ええと、今では猫と犬は違います。このように、関数のマークアップを再度貼り付けます。

猫vtable犬vtable Tiger vtable
 + ----------------- + + ----------------- + + ----------- ------ +
 | タイプのもの|  | タイプのもの|  | タイプのもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | 動物のもの|  | 動物のもの|  | 動物のもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | ネコのもの|  |  |  | ネコのもの|
 + ----------------- + + ----------------- + + ----------- ------ +
 | ペットのもの|  | ペットのもの|
 + ----------------- + + ----------------- +

いいねそれだけがスケーリングしません。各仮想関数テーブルに理論的に必要なインターフェイスを含めることができるように、各インターフェイスには独自のバイアスが必要であることがわかりますが、これは、 各テーブルがすべてのインターフェイスに関する情報を例外なく格納する必要があることも意味しますはい、テーブルの最後で未使用のスペースを切り捨てることができますが、これは小さな慰めであり、メモリが無駄になりすぎます。また、動的ライブラリからインポートされたインターフェイスのオフセットを知ることはできません。したがって、ほとんどの言語では、関数テーブルは実行時にのみ定義されます。

しかし、Rustはそれとは何の関係もありません。 Rustは、仮想テーブルを型に保存しません。 Rustの特性オブジェクトは、いわゆるシックポインターです。 ＆Petは1つのポインターではなく、データと仮想テーブルへの2つのポインターです。一方、特性オブジェクトの仮想テーブルは特定のタイプに関連付けられていません。タイプの組み合わせごとに固有です。

猫のペットvtable犬のペットvtable
+ ----------------- + + ----------------- +
 | タイプのもの|  | タイプのもの|
+ ----------------- + + ----------------- +
 | ペットのもの|  | ペットのもの|
+ ----------------- + + ----------------- +

同様に、Animal + PetとAnimal + Felineのセットには異なるテーブルがあります。つまり、関数テーブルは型の一意のセットごとに単形化されます。

このアプローチは、仮想関数テーブルを構築する問題を完全に排除します。仮想化に関与しない値は追加のデータを保存せず、Petを実装する任意のタイプで、 1つまたは別のPet関数がどこにあるかを静的に決定できます。

この方法の欠点もあります。太いポインターは2倍のスペースを占有するため、ポインターが多いと問題になります。また、要求されたタイプの組み合わせごとに関数テーブルを単形化します。。これは、ある特定の時点で各オブジェクトのタイプを静的に検出できるという事実と、同様に特性オブジェクトのすべての縮小により可能です。ここで単相化を仮想化に置き換えると、パフォーマンスが大幅に低下します。（また、したがって、言語は型をキャストする能力が非常に限られています-約per。）。

注意：障害を見つける機会！

太いポインターは、原則として、太いポインターにさらに一般化できます。「太いポインター」として、Animal + Felineタイプは1つの共通仮想テーブルを指しますが、このテーブルを各特性ごとに別々に2つに分割しない理由はありません。理論的には、これにより、ポインターがさらに太くなるため、テーブルの単相性が制限される可能性があります。このアイデアは定期的に浮上しますが、誰も真剣に受け止めません。

最後に、ユーザーが単相インターフェースを仮想化できるという最近の声明を思い出してください。これは、「トレイトの実装トレイト」（トレイトのイントレイトトレイト）、またはむしろ-トレイトオブジェクトが独自のトレイトを実装することで可能になりました（IMHO型システムの最もクールな機能-約Per。）。結果として、このコードは有効です。

 //   ... trait Print { fn print(&self); } impl Print for i32 { fn print(&self) { println!("{}", self); } } impl Print for i64 { fn print(&self) { println!("{}", self); } } // ?Sized ,  T    (&, Box, Rc,   ). // Sized (  ) - ,   . //      Traits  [T]  " ". //  `T: ?Sized`,      //    T  ,    , //   Sized    . fn print_it_twice<T: ?Sized + Print>(to_print: &T) { to_print.print(); to_print.print(); } fn main() { //      :  . print_it_twice(&0i32); // 0, 0 print_it_twice(&10i64); // 10, 10 //      i32::Print  i64::Print. let data: [Box<Print>; 2] = [Box::new(20i32), Box::new(30i64)]; for val in &data { //  :    . //   &Box<Print>  &Print ,   //   -     ... print_it_twice(&**val); // 20, 20, 30, 30 } }

かっこいい。完璧ではありませんが、楽しいです。残念ながら、Box <Trait>のimpl Traitはありません。Box <T>のimpl <T：Trait> Traitとうまく相互作用しないようですが、まだ掘り下げていません。たぶん、それは十分だし、その事実T我々サイズの？

どこ条件

古い例：

 impl<T> Generic<T> { // ,   :   `equal`  , //  ,   . // (`x == y`     `y == x`).       , //   `T: Equal<U>`   ?       //   `T`,   `U`   ! //   . fn my_equal<U: Equal<T>>(&self, other: &Generic<U>) -> bool { other.data.equal(&self.data) } }

これで、型を関連付ける方法がわかりました。これはどのように役立ちますか？

 //  :      //   " ",       //   ,    Item! fn min<I: Iterator<Item = T>, T: Ord>(mut iter: I) -> Option<I::Item> { if let Some(first) = iter.next() { let mut min = first; for x in iter { if x < min { min = x; } } Some(min) } else { None } }

そして、ここに解決策があります-「どこ」条件。

 impl<T> Generic<T> { fn my_equal<U>(&self, other: &Generic<U>) -> bool where T: Equal<U> { self.data.equal(&other.data) } } fn min<I>(mut iter: I) -> Option<I::Item> where I: Iterator, I::Item: Ord, { if let Some(first) = iter.next() { let mut min = first; for x in iter { if x < min { min = x; } } Some(min) } else { None } }

どこで特性を任意の型に制限できます。多かれ少なかれ。これは、署名で型をインライン化するよりも柔軟性があります。どこにあなたが特色、特性の定義、関数、構造体、列挙型の実装に固執することができます-大まかに言えば、どこジェネリック型があります。

また、いくつかの定義は、脳を作るための動きと陽気になることがあり（読み取り、誰もが<T>どこMyReference用に送信IMPL ＆T：送信初めて（そしてさらに楽しくなります。 - prim.per））から、どこ形質との相互作用-オブジェクトにはいくつかの特殊効果も伴います。値によって自分自身を参照することを意味する特性は、特性オブジェクトでは使用できないことを覚えていますか？要するに、特殊効果はこれを修正できます：

 trait Print { fn print(&self); // `where Self: Sized` ,  //   - . , //   Print  -! fn copy(&self) -> Self where Self: Sized; } impl Print for u32 { fn print(&self) { println!("{}", self); } fn copy(&self) -> Self { *self } } fn main() { let x: Box<Print> = Box::new(0u32); x.print(); }

高次特性の制限

この時点で屋根がまだなくなっていない場合は、次のセクションでは屋根を開けないので、幸運です。率直に言って泥だらけの沼地が発生し、ここで説明されますが、傷型システムの悪名高い狂信者だけがピッキングを楽しむことができます。

次に、高機能の関数を作成します。これらの関数は、「関数で機能する関数」です。美しく有名な例はmap（）です：

 let x: Option<u32> = Some(0); let y: Option<bool> = x.map(|v| v > 5);

5杯のコーヒーが戻ると、Rustが特性を介して行う控えめなコメントに出くわすかもしれません。「ああ、すごい、素晴らしい特性だ、そうだった」とあなたは言い、すぐに「しかしそれはただの特性だ！」ここにあります：Fn、FnMutおよびFnOnce。今、私たちにとってそれらの違いは取るに足りないものであり、私たちは彼らから、私たちが説明したいものにもっと美しくかかっているものを取り上げます。

Fnは実際には特性ではなく、特性のファミリーです。Fn（A、B）-> Cは、すでに特性です。ジェネリックのようなもの。そうであっても：これは一般的なものです。Fn（A、B）-> C-直接利用できない一般化された特性の上にある構文糖（少なくともバージョン1.7の場合）。コンパイラはそれを展開しますFN <（A、B）、C出力=> 。着信タイプ、発信タイプは明確に表示され、すべてが私たちの言うとおりです！

これに基づいて、map（）の例のクロージャはFnOnce（u32）-> boolを実装します。これまでのところ、まったく怖くない。これまで。

 fn get_first(input: &(u32, i32)) -> &u32 { &input.0 } fn main() { let a = (0, 1); let b = (2, 3); let x = Some(&a); let y = Some(&b); println!("{}", x.map(get_first).unwrap()); println!("{}", y.map(get_first).unwrap()); }

実際にどのget_first特性がここに実装されていますか？同様に>＆U32 -のFn（＆（U32、I32）） ？2行目。

 trait MyFn<Input> { type Output; } // -;    //  ,      . struct Thunk; impl MyFn<&(u32, i32)> for Thunk { type Output = &u32; }

 <anon>:9:11: 9:22 error: missing lifetime specifier [E0106] <anon>:9 impl MyFn<&(u32, i32)> for Thunk { ^~~~~~~~~~~ <anon>:9:11: 9:22 help: see the detailed explanation for E0106 <anon>:10:19: 10:23 error: missing lifetime specifier [E0106] <anon>:10 type Output = &u32; ^~~~ <anon>:10:19: 10:23 help: see the detailed explanation for E0106 error: aborting due to 2 previous errors

生涯のない借用は純粋な再編です。鉄則：借入がタイプの一部である場合-ライフタイムを適用してください！もう1つは、Rustは99％のケースでこのルールに負担をかけないほど賢明であるということです。デフォルトのライフタイムを置き換えるだけです（逐語的に翻訳するのにあまり意味のない別の用語で、誰もがそれを使用します-およそPer。）。実際のところ

、get_first、実際にそのようなモンスターがあります：

 fn get_first<'a>(input: &'a (u32, i32)) -> &'a u32 { &input.0 }

別のルール：関数の署名を借用すると、関数はそれらに関して一般化されます。したがって、一般化された特性を実装する必要があります。

 trait MyFn<Input> { type Output; } struct Thunk; impl<'a> MyFn<&'a (u32, i32)> for Thunk { type Output = &'a u32; }

コンパイルします。そして今、私はあなたに反対を言います：私たちが必要とする特性はFn（＆（u32、i32））->＆u32です。そこに、私はあなたに嘘をついた。方法と理由、イテレーターのフィルターの例を示します。

 ///    struct Filter<I, F> { iter: I, pred: F, } ///   fn filter<I, F>(iter: I, pred: F) -> Filter<I, F> { Filter { iter: iter, pred: pred } } impl<I, F> Iterator for Filter<I, F> where I: Iterator, F: Fn(&I::Item) -> bool, // !   -   !   ? { type Item = I::Item; fn next(&mut self) -> Option<I::Item> { while let Some(val) = self.iter.next() { if (self.pred)(&val) { return Some(val); } } None } } fn main() { let x = vec![1, 2, 3, 4, 5]; for v in filter(x.into_iter(), |v: &i32| *v % 2 == 0) { println!("{}", v); // 2, 4 } }

見知らぬ人と奇妙な。lifetime ＆val を扱うにはpred（）が必要です。残念ながら、where （）条件をnext（）に掛けても、このライフタイムを明示的に指定することはできません（一般的に、Iteratorはこれを許可しません）。このライフタイムは、関数内で単に表示および非表示になり、選択も名前の指定もできません。また、名前を呼び出せない人と作業するにはpred（）も必要です！私たちは額に登ります- 人生のすべての時間で働くためにpred（）が必要です。突然：

 F: Fn(&I::Item) -> bool

それは砂糖です

 for<'a> F: Fn(&'a I::Item) -> bool

つまり、<'a>はほとんど逐語的に読まれます：for all' a（for all 'a）！

レッツ・コールこの制約高次の特性（（HRTB）バインド上位特性）。複雑な型構造を持つある種の沼地に既に吸い込まれていない限り、それらを操作する必要はありません。通常、HTRBは機能特性を操作するときに表示され、そこでも構文糖で覆われています。つまり、多くの場合、ユーザーに対して透過的です。現時点では、高次特性の制限は有効期間でのみ機能します。

高次タイプ

ジェネリックは本質的に高次の型を表現する方法であることは既に述べました。Vecは（T）-> Vec <T>という形式の型コンストラクターと考えることができます。impl <T> Vec <T>のTraitまたはfn make_vec <T>（）-> Vec <T>のような汎用コードを記述するときに、この型コンストラクターを意味できます。また、制限についても覚えています-型コンストラクターについて言えば、この発信型を示す義務があります。つまり、コンストラクタ自体を一般化することはできません。

たとえば、参照カウントポインターを使用するデータ構造が必要です。 Rustには、RcとArcの 2つのオプションがあります。Rc生産的、Arcはスレッドセーフです。構造の実装の観点から、これらの型は完全に交換可能であると仮定します。ただし、構造体のユーザーにとっては、どのポインターカウンターを使用するかが非常に重要です。

もちろん、RcとArcに関して構造を一般化する必要があります。理想的には、次のように書きます。

 //   ,   .   ! ///     . /// RefCount   Rc  Arc,    . struct Node<RefCount: RcLike, T> { elem: T, next: Option<RefCount<Node<RefCount, T>>>, }

くそー、それはできません！ユーザーはここでRcまたはArcを送信できないため、これはわかりません。型は一般化されており、Rc <SomeType>のように、型引数をスリップすることにより完成する必要があります。セットRc <Node <T >>の特性を考え出すこともできますが、これはRcとArcを直接操作するよりも消化されにくいです。これは、ローンを返すジェネリックでも次のように使用できます。

 /// ,    `next` , ///      . trait RefIterator { type Item; fn next(&mut self) -> &mut T }

既に知っているように、それはただの砂糖です

 trait RefIterator { type Item; fn next<'a>(&'a mut self) -> &'a mut Self::Item; }

ここで厄介な点は、借用を、型から外部に突き出る極端なオブジェクトとしてハードコーディングしたという事実です。つまり、Self :: Itemをどこかに格納する必要があります。喜んでこのローンを投げてこの問題を解決します。

 trait RefIterator { type Item; fn next<'a>(&'a mut self) -> Self::Item<'a>; }

Self :: Item =＆mut Tを書くことができ、理論的には満足しているため、さらに美しく、一般化されているように見えます。Itemが静かに型コンストラクターに変わり、一般化できないことに気付くまで！

コンパイラーによく尋ねれば、できます。しかし、私はあなたにそれを伝えませんでした。~~オフィスを撮影しないでください。~~

ここでの重要な知識は、特性には入力タイプと出力タイプがあることを理解することです。つまり、特性はタイプの上にある関数です。ここを見てください：

 trait TypeToType<Input> { type Output; }

型コンストラクタ！汎用RefIterリンクカウントイテレータを実装しましょう。

 use std::marker::PhantomData; use std::mem; use std::cmp; // ,  RefIter    struct MyType<'a> { slice: &'a mut [u8], index: usize, } //     : trait LifetimeToType<'a> { type Output; } // - , //      /// &'* T struct Ref_<T>(PhantomData<T>); /// &'* mut T struct RefMut_<T>(PhantomData<T>); /// MyType<*> struct MyType_; //   ,      impl<'a, T: 'a> LifetimeToType<'a> for Ref_<T> { type Output = &'a T; } impl<'a, T: 'a> LifetimeToType<'a> for RefMut_<T> { type Output = &'a mut T; } impl<'a> LifetimeToType<'a> for MyType_ { type Output = MyType<'a>; } //   ,   ! // `Self::TypeCtor as LifetimeToType<'a>>::Output` // -   'a  TypeCtor. // // , : <X as Trait>::AssociatedItem  " -", //      . // // :  ,     HRTB, //    `T: 'a`. // `for<'a> Self::TypeCtor: LifetimeToType<'a>`   // `&'a T`    `'a`, //       `T: 'static`! //    "where"  `next`. trait RefIterator { type TypeCtor; fn next<'a>(&'a mut self) -> Option<<Self::TypeCtor as LifetimeToType<'a>>::Output> where Self::TypeCtor: LifetimeToType<'a>; } // ! struct Iter<'a, T: 'a> { slice: &'a [T], } struct IterMut<'a, T: 'a> { slice: &'a mut [T], } struct MyIter<'a> { slice: &'a mut [u8], } // FIXME: https://github.com/rust-lang/rust/issues/31580 //      ,    . //         // (     ,   ) fn _hack_project_ref<'a, T>(v: &'a T) -> <Ref_<T> as LifetimeToType<'a>>::Output { v } fn _hack_project_ref_mut<'a, T>(v: &'a mut T) -> <RefMut_<T> as LifetimeToType<'a>>::Output { v } fn _hack_project_my_type<'a>(v: MyType<'a>) -> <MyType_ as LifetimeToType<'a>>::Output { v } //  (   ) impl<'x, T> RefIterator for Iter<'x, T> { type TypeCtor = Ref_<T>; fn next<'a>(&'a mut self) -> Option<<Self::TypeCtor as LifetimeToType<'a>>::Output> where Self::TypeCtor: LifetimeToType<'a> { if self.slice.is_empty() { None } else { let (l, r) = self.slice.split_at(1); self.slice = r; Some(_hack_project_ref(&l[0])) } } } impl<'x, T> RefIterator for IterMut<'x, T> { type TypeCtor = RefMut_<T>; fn next<'a>(&'a mut self) -> Option<<Self::TypeCtor as LifetimeToType<'a>>::Output> where Self::TypeCtor: LifetimeToType<'a> { if self.slice.is_empty() { None } else { let (l, r) = mem::replace(&mut self.slice, &mut []).split_at_mut(1); self.slice = r; Some(_hack_project_ref_mut(&mut l[0])) } } } impl<'x> RefIterator for MyIter<'x> { type TypeCtor = MyType_; fn next<'a>(&'a mut self) -> Option<<Self::TypeCtor as LifetimeToType<'a>>::Output> where Self::TypeCtor: LifetimeToType<'a> { if self.slice.is_empty() { None } else { let split = cmp::min(self.slice.len(), 5); let (l, r) = mem::replace(&mut self.slice, &mut []).split_at_mut(split); self.slice = r; let my_type = MyType { slice: l, index: split / 2 }; Some(_hack_project_my_type(my_type)) } } } // ! fn main() { let mut data: [u8; 12] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]; { let mut iter = Iter { slice: &data }; while let Some(v) = iter.next() { println!("{:?}", v); } } { let mut iter = IterMut { slice: &mut data }; while let Some(v) = iter.next() { println!("{:?}", v); } } { let mut iter = MyIter { slice: &mut data }; while let Some(v) = iter.next() { println!("{:?} {}", v.slice, v.index); } } }

上記で何が起こっているかを解読できるかどうかはわかりませんが、これが必要かどうかはわかりません。ここで説明した通常の一連のアクションです。一般に、Rc / Arcの処理に役立ちますか？

そしてはい！

 use std::rc::Rc; use std::sync::Arc; use std::ops::Deref; //   T -> Output trait RcLike<T> { type Output; fn new(data: T) -> Self::Output; } //  struct Rc_; struct Arc_; impl<T> RcLike<T> for Rc_ { type Output = Rc<T>; fn new(data: T) -> Self::Output { Rc::new(data) } } impl<T> RcLike<T> for Arc_ { type Output = Arc<T>; fn new(data: T) -> Self::Output { Arc::new(data) } } struct Node<Ref, T> //  `where`     ( - ) where Ref: RcLike<Node<Ref, T>>, { elem: T, //  : Option<Rc<Node<Rc_, T>> next: Option<<Ref as RcLike<Node<Ref, T>>>::Output> } struct List<Ref, T> where Ref: RcLike<Node<Ref, T>>, { head: Option<<Ref as RcLike<Node<Ref, T>>>::Output> } impl<Ref, T, RefNode> List<Ref, T> where Ref: RcLike<Node<Ref, T>, Output=RefNode>, RefNode: Deref<Target=Node<Ref, T>>, RefNode: Clone, { fn new() -> Self { List { head: None } } fn push(&self, elem: T) -> Self { List { head: Some(Ref::new(Node { elem: elem, next: self.head.clone(), })) } } fn tail(&self) -> Self { List { head: self.head.as_ref().and_then(|head| head.next.clone()) } } } fn main() { //  ( ,      ) let list: List<Rc_, u32> = List::new().push(0).push(1).push(2).tail(); println!("{}", list.head.unwrap().elem); // 1 let list: List<Arc_, u32> = List::new().push(10).push(11).push(12).tail(); println!("{}", list.head.unwrap().elem); // 11 }

私たちはほとんど変わっが、上記の条件妨げ句参考：RcLike <ノード<参考、Tを>>。これは、抽象化の穴です。一方で、私たちの構造のユーザーはNodeについて絶対に知る必要はありませんが、一方で、そこに言及することを強制されます。そして、Refは何でもRcLike であると言えます。技術的には、これは<T> Ref：RcLike <T>の場所のように聞こえます。これにより、Refの使用に関するオプションの配布の詳細を隠すことができます。

ああ。 , , . - , , ! .

( , RFC , , -, — ..)

, , , , , , Rust . , .

同じタイプの2つのインスタンスが実際に交換可能であると考えたことはありますか？そのため、2つのWidgetがあり、それらを交換した場合、誰もリードしません。ほとんどの場合、これは大歓迎です。しかし、同じタイプのインスタンスの交換を禁止するとどうなりますか？

たとえば、配列。配列を反復処理するとき、通常は要素を取得するために行われます。：まあ、このタスクは、アクセス要素に異なるニーズに適したイテレータを提供することが必要ですイーター、IterMutとIntoIter。反復子が私たちに語った場合、それはより便利ではないでしょうどこに見えるために、私たちは自ら決めたかをそこにホストする？

理論的には、配列に独自のインデックスイテレータがあれば可能です。0、1、2、...、lenの1 - 。インデックス、ビジネスで自分自身を実行し、誰もが幸せです。この場合にのみ、イテレータの信頼性が影響を受けます。通常、イテレータからは、各要素が少なくとも1回トラバースされることが確実であることが期待され、落下することは保証されていません。

インデックスによるアクセスは、上記のすべてを破壊します。インデックスを置き換えることができ、配列自体を変更してインデックスを無効にすることができます。最後に、ある配列のインデックスを誤って別の配列にプルすることができます。しかし、これはすべて、さまざまな程度の努力で解決可能です。インデックスの置換に対して-それらの型ラッパーであるため、ユーザーは実際の値を使用できません。インデックスの無効化に対して、インデックスを配列の寿命にリンクすると役立ちます。

そして、配列自体の置換では、どうですか？ 2つの配列があり、それらのインデックスのタイプは同一であり、事実上交換可能ですが、これは望ましくありません。私たちを取得する方法（UN）が呼ばれたい一般化（ジェネ）。一般化可能性は、異なる関連型を持つ同じ型の異なるインスタンスを所有するという考えに基づいています。関連付けられた型の値は、型インスタンス、つまりです。

疲れた、ひどく疲れた。とにかくここでフィニッシュラインに近づいているので、先ほど書いた上記のデモをコピーします。とにかく、すべてがコメントにあるので、読んでください。

 //      , //       ""  //   .        , //    ,     . // (      Vec,        ). // //     "   ",  //   .      //   ,         , //      ( ?).    //   ,      ,    //       ,     . //     .    //       (let idx = arr.validate(idx)). // //     -    //  ,    ,   //       ( moving values in/out  try!). //  ,        //   , ,    ,  . //          //  API ( ,    Vec --     `push`  `pop`. //       . // //     ,        , //       ,        // //      gereeter    //    BTreeMap.  ST Monad  Haskell   . // //      ,     //     &[T]  &mut [T]. fn main() { use indexing::indices; let arr1: &[u32] = &[1, 2, 3, 4, 5]; let arr2: &[u32] = &[10, 20, 30]; //   ( ,     ) indices(arr1, |arr1, it1| { indices(arr2, move |arr2, it2| { for (i, j) in it1.zip(it2) { println!("{} {}", arr1.get(i), arr2.get(j)); //        // println!("{} ", arr2.get(i)); // println!("{} ", arr1.get(j)); } }); }); //   ,      let _a = indices(arr1, |arr, mut it| { let a = it.next().unwrap(); let b = it.next_back().unwrap(); println!("{} {}", arr.get(a), arr.get(b)); // a //   ,    }); //     ,    let (x, y) = indices(arr1, |arr, mut it| { let a = it.next().unwrap(); let b = it.next_back().unwrap(); (arr.get(a), arr.get(b)) }); println!("{} {}", x, y); //  :    !? // (:        ) } mod indexing { use std::marker::PhantomData; use std::ops::Deref; use std::iter::DoubleEndedIterator; // Cell<T>   T;  Cell<&'id _>  `id` . //  ,         // 'id  "" . type Id<'id> = PhantomData<::std::cell::Cell<&'id mut ()>>; pub struct Indexer<'id, Array> { _id: Id<'id>, arr: Array, } pub struct Indices<'id> { _id: Id<'id>, min: usize, max: usize, } #[derive(Copy, Clone)] pub struct Index<'id> { _id: Id<'id>, idx: usize, } impl<'id, 'a> Indexer<'id, &'a [u32]> { pub fn get(&self, idx: Index<'id>) -> &'a u32 { unsafe { self.arr.get_unchecked(idx.idx) } } } impl<'id> Iterator for Indices<'id> { type Item = Index<'id>; fn next(&mut self) -> Option<Self::Item> { if self.min != self.max { self.min += 1; Some(Index { _id: PhantomData, idx: self.min - 1 }) } else { None } } } impl<'id> DoubleEndedIterator for Indices<'id> { fn next_back(&mut self) -> Option<Self::Item> { if self.min != self.max { self.max -= 1; Some(Index { _id: PhantomData, idx: self.max }) } else { None } } } pub fn indices<Array, F, Out>(arr: Array, f: F) -> Out where F: for<'id> FnOnce(Indexer<'id, Array>, Indices<'id>) -> Out, Array: Deref<Target = [u32]>, { //    .      //         (,  //  F).   ,    `indices`  //  ,       . // //          //  ,     `'static`,      ,     //  *this*.           . //       ,    ,  //           // ,     . // //       , //     ,     ,      . //   ,        , //        . let len = arr.len(); let indexer = Indexer { _id: PhantomData, arr: arr }; let indices = Indices { _id: PhantomData, min: 0, max: len }; f(indexer, indices) } }

ムハハ、そんなに簡単じゃない？いいえ、純粋な地獄。そして、これはすべて息をのむほど安全でなく、壊れやすいものです。これに対して、安全でないサウンドを使用することに対するRustの主張は、落下する建物に誓わない丁寧な要求のようなものです。システムの安定性はすべてのタイプのフィリグリーフィット（および寿命、特に寿命-約Per。）に依存します最も危険な状態、一方、安全でないとマークされた行はキャンバス上の唯一の条件です。

プログラムの一般化可能性への依存は、粉末倉庫での喫煙にすぎないので、既存の構文のあまり知られていない隅からHTRBから少しずつ収集するのではなく、Rustの一般化可能性を直接サポートすることを本当に期待しています。

とにかく、それで十分です。何も書く力はこれ以上ありません。すべてがどこにも引っ張られませんでした。許してください。お願いします。

Rustでコードを再利用する多くの方法

コード再利用原則の概要

単相

仮想化

乗り換え

Rustはどうですか？

マクロ

言及する価値がある：構文拡張とコード生成

乗り換え

特性

トピック：一貫性

ジェネリック

また重要：型定義と演算子「ターボフィッシュ」

特性オブジェクト

注意：障害を見つける機会！

関連するタイプ

どこ条件

高次特性の制限

高次タイプ

More articles: