型相対パスを考慮したパス解決ここまでで説明したのは型相対ではない場合のパスの解決でした。これに加えて型相対パスを考慮した解決を行います。未解決として返します。解決を試み、解決できたところまでを返します。場合は単に解決できたところまでを返します。形式のパスの解決に失敗した場合、プリミティブ型へのフォールバックが検討されます。<i32>::max_value}プリミティブ型へのフォールバックは、以下の条件で発生します。名前解決の時点で解決できるはず)なので、先頭セグメントをプリミティブ型名として読み替え、型相対パスとして解釈します。スコープ内トレイトの列挙インポート解決で得られた結果は、パス解決のほかに、スコープ内トレイトの列挙のためにも使われます。これはRustの以下の規則のために必要です。自身の固有実装のほか、スコープ内にあるトレイトの実装から探索される。しの適用後を含む)型の固有実装またはスコープ内にあるトレイトの実装から探索される。関連アイテムやメソッドの解決をスコープ内トレイトに限定することで、「依存ライブラリを増やしただけで勝手にメソッド名の解決順が変わる」というような不安定な挙動を極力抑える意図があるものと思われます。「スコープ内」と言っているだけあって、これは通常のパスの最初のセグメントの解決とほぼ同じ挙動をします。具体的には以下の優先順位で探索が行われます。現在実装中のトレイトレキシカルスコープ内のトレイト衛生的レキシカルスコープ内のトレイト通常のプレリュード内のトレイト2から4はほぼ同じなので省きます。「現在実装中のトレイト」が探索されることで以下のようなコードが許容されています。+1した状態で保存される整数。Optionと組み合わせたときの空間効率が良い。書けるのは、実装中のトレイトが使われているおかげです。ちなみにトレイト自身のデフォルト実装では、そもそもトレイトがスコープ内にあることが普通なのでこのような特別対応は必要ありません。それによって以下のようなコーナーケースは発生しているようです。}}まとめ(5)でモジュールグラフが作られ、(6)でパスの解決ができたので、これで名前解決の担当範囲はおおよそ理解できたことになります。名前解決とマクロの相互作用についてはきちんと扱っていなかったので、次回は最後にその話をして終わりにしたいと思います。Rust2018以降、Rustのモジュールシステムは入門しやすく、かつマスターしにくくなりました。そこで本記事では、その両方を達成することを目指しました。同じテーマで、Rust2018を考慮して改めてまとめ直したものです。本記事中のサンプルコードの多くは、Rustの細かい仕様や実装を調べるためのものであり、実際に有用なプログラミングパターンであるとは限りません。実質的にバグに近い挙動を説明しているものもあるため、将来にわたって同じ動作であることはあまり保証できません。そのアイテムを名指ししていいかどうかのアクセス制御をする仕組みで、Rustにおける実装のカプセル化のために使われます。RFC1422にてモジュール固有の可視性が実装されました。RFC1560が実質的にRFC1422の事前準備としての役割を果たしているため、こちらも要チェックです。可視性は名指しできるアイテムには基本的に付与されます。付与されないものとして以下があります。実装は型で索引されるため、可視性で管理するものではないという考えだと思われる。有無で制御されてきたため?RFC1561では宣言マクロ2.0の一部として可視性の統一を目指す案も記載されている逆に、アイテム以外に付与されるものとして以下があります。可視性の指定は意味的には2種類(+α)に分けられます。どこからでも参照できる。特定モジュール以下から参照できる。アイテム自身からも見えないというのはおかしいので、ユーザーに見えるところでは出てこない。書くと公開になります。モジュール限定を指定するための記法がたくさんあります。以下が可視範囲となる。