この2つは名前解決の観点からは大きく異なります。型相対パスなので、基本的に名前解決ではほとんど何もできずに型推論にその処理を委ねることになります。ほうは実際は単なるジェネリクスパラメーターのついたパスです。第0ジェネリクスパラメーターであるという原則を念頭に置いて、以下のコードを眺めるとそれがわかると思います。AをBに変換できるということである。DefRustにおける名前解決はコンパイラのフェーズのひとつで、パス(の途中まで)をDefに解決する処理です。src/librustc/hir/def.rsに定義があります。含まれていないことに注意してください。これらは既存のDefと同じものを作ります。別のDefということになります。名前解決は「パス(の途中まで)をDefに解決する処理」と書いた通り、名前解決の時点ではパスが完全には解決されない場合があります。書いた時点では確定できないためです。scope}これは、型を明示することで解決できます。Option::<&i32>::cloned(Some(&42));}この「型を使って解決する」というのは、もっと複雑な形で現れることもあります。以下のように書いても解決されます。IntoIterator>::Item>::cloned(Some(&42));}こういうものまで名前解決の時点で解決しようとすると複雑になりすぎるため、型に依存して決まる部分は名前解決より後のフェーズ(型推論・型検査)で行われます。そのため、名前解決では以下のようにパスのどこまでが何というDefに解決されたかを最終的な解決結果として用います。usize,}たとえば、名前解決は以下のところまで解決します。ここまで同じ理由で、メソッド名も名前解決では処理されません。これがOption::unwrapなのかResult::unwrapなのかは後で決まるこのように、ここで解説している「名前解決」の範疇では型推論に頼らない範囲での解決しか行いません。この2段階解決の仕組みを頭に入れておくと構造の整理がつけやすいと思います。名前解決の責任範囲は明確になりました。その手順を少し細かく割ると以下のようになります。