そのRFCには4つの異なる機能がありください。

@ retep998 RFCの説明全体で説明されているように、これらの機能はグローバルな設計上の考慮事項を通じて接続されています。 たとえば、クレートの名前を変更するための外部メカニズムを提供することは、最終的にextern crate廃止されることによって部分的に動機付けられます。 さまざまな側面を個別にゲートすることができます（また、異なる構文を試すためにいくつかの重複するゲートがある可能性があります）が、全体的な設計と安定化について議論するには、グローバルな一貫性を念頭に置くことが重要です。

木枠の名前を変更するための外部メカニズムを持つことは、すでに何年にもわたって望まれ、必要とされており（https://github.com/rust-lang/cargo/issues/1311）、単独で問題なく動作する可能性がありますが、代わりに使用されていますextern crate殺害をサポートするポーンにすぎません。

これまで、密接に関連する機能に対して個別のRFCを使用することに問題はありませんでしたが（ repr(align(N))とrepr(packed(N))のRFCが思い浮かびます）、今ではfoo/mod.rsを変更すると主張しています。 foo.rsはextern::とcrate::と密接に関連しているため、同じRFCに属し、同じ追跡の問題を使用する必要がありますか？

これは構文の未解決の質問の比較的微妙な側面であるため、この点に注意してください。可視性修飾子およびパスプレフィックスとしてcrateを使用すると、 crate ::absolute::pathとcrate::relative::path 。 コンテキストキーワードを使用すると、同じあいまいさが生じます。可視性修飾子として実際に意味のある予約キーワードは他にありません。

したがって、（少なくとも） crate可視性修飾子を省略し、既存のpub(crate)を使用して実験したいと思います。

foo.rs / foo/mod.rsポイントを別の追跡問題に分割してもかまいません。これは、パスと可視性修飾子の変更とはまったく無関係に見えるためです。

限り外部クレートリネームとして...すでにそれ用に別の問題があるのでしょう同様にそれの罰金はこの1つの一部であると思いますので、それはパスの変更のためにかなり重要です。

可視性修飾子（パスプレフィックスではない）としてのcrateの選択に関して数週間前に多くの議論がありましたが、このキーワードの選択が「未解決の質問」としてリストされていたにもかかわらず、私はがっかりしました。 RFC、それは明らかに今忘れられています。 私自身、および私が指摘した他のいくつかの人は、この選択は形容詞/修飾子ではなく、あいまいになる可能性があるため、混乱を招きます。 crateは、クレートのパブリックAPIの一部を意味しますか？ 番号！ これは、クレートに対してlocalまたはinternalまたはpub （洗練された）を意味します（したがって、後者のキーワードを好む理由）。 したがって、私は即時の変更を要求していませんが、少なくともこの追跡の問題では未解決の質問であることを認め、安定化の際に忘れられないようにします。

このモジュールの再設計がこれまでに進んだことは素晴らしいことですが、同時に、「impl期間」を作成するためだけに失敗せず、Rustユーザーの大多数に相談せずに決定を下すことが重要です。 そして、残念ながら、Github RFCの議論に関与している人々は、ユーザーベース全体を代表しているわけではないと思います。情報/コメント/意見が殺到しているため、落胆する可能性があります。 だからどういうわけかそれも対処する必要があります。

実装がどのように終わったかは明らかではありません...

@rpjohnst @ retep998 foo.rs + foo/について議論し、このRFCのいくつかの改善を提案するために、新しいRFCを開きました。

編集：可視性修飾子としてcrateについて議論するために、別のRFCを開くことをお勧めします。 個人的には反対のことを望んでいます。 pub(extern)が追加され、外部で公開されているすべてのシンボルに必要です。 これにより、裸のpub pub(crate)は、次のエポックの

@rpjohnst

クレート::絶対::パスとクレート::相対::パスの間に解析のあいまいさを導入します

とにかくcrate ::relative::path無効なコードではありませんか？ 解析中に拒否することはできませんか？

@ est31いいえ、解析中に名前解決を行う必要がありますが、これは絶対にやりたいことではありません。 これは、CおよびC ++の解析で最も厄介な部分のひとつであり、 a * bが乗算または宣言であり、 a b(c, d);が変数宣言または関数プロトタイプであるという同様のあいまいさがあります。

同じ名前の依存関係とトップレベルモジュールを許可し始めた場合、名前解決を解析と組み合わせても節約できませんcrate :: some :: itemはcrate -visible itemなる可能性がありますsome 、またはプライベートitem最上位モジュールからsome 。

これを視野に入れておくために、あいまいさをいずれかの方法で任意に解決し、他のケース（おそらく最もまれに見えるcrate -visibility絶対パスケース）を記述するために括弧を要求することができますが、それでもpub(crate)に固執すれば必要のないフットガンで、構文のあいまいさはすでに解決されています。

クレートを可視性修飾子およびパスプレフィックスとして使用すると、 crate ::absolute::pathとcrate::relative::path間に解析のあいまいさが生じます。

タプル構造体フィールドと「インライン」絶対パスの両方の可視性がまれであることを考えると、これは小さな問題、IMOです。
現在、パスは常に貪欲に解析されるため、 crate :: x :: yがcrate::x::yを意味することは理にかなっています。
反対の意味が必要な場合は、 pub(crate) ::x::yまたはcrate (::x::y)を使用できます。

@rpjohnst @petrochenkov pub ::relative::pathが有効なコードであるコード例を教えてください。 2つのケースのいずれかが無効であると思うので、あいまいさのすべてを理解することはできません。

編集：これが関連する

@ est31あなたは間違った考えを持っているようです-それは相対パスに関するものではなく、決して問題ではありません。 名前が何を指しているのかを知る前に、ASTを構築することです。 完全なサンプルは次のとおりです。

struct S(crate :: x :: y);

これらの名前をまだ検索することが許可されていない場合、その文字列をASTに変換するにはどうすればよいですか。 考えられる答えは2つあります。 1つには、現在のクレートのモジュールxで定義されたタイプyプライベートフィールドがあります。 もう1つは、依存関係の最上位x定義された別のタイプy crate可視フィールドを持っています。 マクロは必要ありません。

@rpjohnst明確にしてくれてありがとう。 その確かにあいまいさ。

@rpjohnst

簡単な解決策は、クレートの可視性修飾子に対して明確に解析するように定義することです。 指定されたタイプのプライベートメンバーを持つタプル構造体として解析する場合は、次のようにします。

    struct S(:: crate :: x :: y);

（ルート '名前空間'を示す::プレフィックスに注意してください）

これは、サブモジュールで他のルート名前空間を参照する必要がある方法と一致しています（例： ::std::x::y ）。

crate -as-a-visibilityに曖昧さをなくすだけでも、いくぶん驚くべきことだと思います。 ただし、この回避策を少し「正規化」して、 crate::が常に先頭の:: （もちろんuse以外）で使用されるようにすることをお勧めします。 ご指摘のとおり、これにより::std::x::yようなパスとの対称性が高まり、真に相対的なパス（ self:: / super:: / something_in_scope::プレフィックスなしの形式が残ります。

これを行う必要がありますか？ useパスでcrate::x::yを許可すると、 crateは魔法のようなものになりますが、 ::crate::x::yを適用すると、依存関係と同じレベルにスコープされます。とにかく暗示しようとしている。

@rpjohnst

crate::が常に先頭の::とともに使用されるようにします（もちろん使用以外）

これは、少なくとも最初は合理的かもしれません（後でこれをリラックスすることを妨げるものは何もありません）。

私はuse extern::bar::fooまたはuse crate::bar::foo構文のファンではありません。 とてもうるさいようです。 これには砂糖がいいです。 これにはextern bar::fooをお勧めします。

もう1つの暗黙のルールを追加するのはどうですか？ extern crateをルート名前空間に自動的にインポートし、より一致するパス式を作成します（私は英語が苦手です。plsは次の例から私の見解を学びます）

例えば

1. このようなプロジェクト構造：

src
| --lib.rs
| --foo.rs
| --foo
| ---- | --bar.rs

1. Cargo.tomlで依存関係を設定します。
   [dependencies] serde = "3.0.0"

2. mod barをmod fooに追加し、mod fooをlib.rsに追加します。

3. lib.rsで関数finlibを定義し、foo.rsで関数finfooを定義し、bar.rsで関数finbarを定義します。

extern crateのスコープをcrateのトップレベルモジュールとして作成すると、このようなコードをどこにでも記述できます。

完全/修飾パスの場合

::serde::Deserialize
::serde::x::y
::finlib                            // not ::crate::finlib
::foo::finfoo                   // not ::crate::foo::finfoo
::foo::bar::finbar           // not ::crate::foo::bar::finbar

このように相対パスを書く

serde::Deserialize      // no need to write `use serde`
serde::x::y                   // no need to write `use serde`
finlib                          
foo::finfoo                  
bar::finbar       

ルート名前空間まで、supper modでルックアップが見つからない場合は、最初に現在のmodスコープでserdefinlibfooをルックアップします。 名前の競合がある場合は、代わりに完全なパスを記述します。

また、foo.rsでself::bar::finbarを使用して、名前の検索を回避することもできます。

これについて説明した以前のスレッドを見つけることができませんが、コンパイラーはそのように機能していたため、名前解決に大きな問題が発生しました。 IIRC @ pcwaltonまたは@ arielb1はおそらくもっと知っています。

このあいまいさに対する最も簡単な解決策は、クレートローカルの可視性修飾子に別のキーワードを使用することではありません（つまり、 pub(crate)置換）。 たとえば、以前のRFCの議論で何度も提案されたように、 local 。 その場合、 struct S(local :: x :: y)はstruct S(crate :: x :: y)とは異なります。

これは、 <visibility> <absolute path>と<relative path starting with the new keyword>間に別のあいまいさをもたらすだけです。これは、新しいキーワードがコンテキストに依存している必要があるためです。

@rpjohnstああくそー..しかし、それはエポックが解決するように設計された問題ではありませんか？ 例：現在のエポックではpub(crate)使用し、次のエポックでは、より「人間工学的」な新しい非コンテキストキーワードを導入します。

@ neon64はい。ただし、RFCによると、新しいエポックは必要ないという主張です。 その主張は成り立たないようです。

現在、 crate可視性またはcrate::パスを使用するコードはないため、新しいコードのみが影響を受けます。 解像度を選択してそれを維持する限り、互換性の問題はありません。

私に起こったことの1つは、以前にディスカッションの1つで取り上げられたことがある場合は、お詫びします（最後のカップルで見たことはありません）。

最新の提案では、「このクレート内」を参照するためのcrate::と、「このモジュール内」を参照するためのself::があります。 これは少し一貫性がなく、潜在的にそれよりも明確ではありません。たとえば、 selfが「これ」を指す場合、本質的に「これは何」であるself::があるという事実からも明らかではありません。 このモジュール」を意味し、 crate::は「他のクレート」を意味する可能性があると推測されるかもしれません。これは、実際にはスレッドで言及されている混乱です。

一つの可能な解決策は、段階的に廃止することですself::の賛成でmod:: 。 次に、「最も近い囲み箱の中」を意味するcrate::と、「最も近い囲みモジュール内」を意味するmod::があり、明確で一貫性があります。 また、 fn::プレフィックスを導入することで、 fnスコープ内のアイテムを修飾された方法で参照できないという問題を解決できる可能性があります。これは、当然のことながら、「最も近い囲みのfn "。 （さらに先に進むことが理にかなっているのかどうか、またtrait::やimpl::ようなものがあるかどうかについては考えていません。）

@glaebhoerlそれは興味深い提案です。 個人的には、絶対パスに新しい構文を導入し、

パスに次の文法があると想像してください。

Path = AbsolutePath | RelativePath
AbsolutePath = 
    | `@` ID? 
    | `@` ID? `::` RelativePath
    | `self` :: RelativePath
    | `super` :: RelativePath
RelativePath = ID (`::` ID)*

この文法では、 @crateで始まる他のクレートからのものを参照します。たとえば、次のようになります。

use <strong i="13">@std</strong>::collections::HashMap;

たとえば、 @だけでローカルクレートを参照します。

use @::something::in::my::crate;

（そして、 use self::somethingは、良くも悪くも、今日と同じままです。）

これの良い点は、絶対パスが相対パスと完全に区別されていることです。つまり、 useからコードにパスをコピーして貼り付けることができるという望ましいプロパティがあり、それが機能します。

fn foo() {
    <strong i="24">@std</strong>::cmp::min(a, b) // OK
}

これは今日は真実ではなく、それは間違いなく時々私を混乱させます。

また、 crate周りの解析のあいまいさを排除するので、 pub Foo(crate @::MyType)などを実行でき、正常に機能します。

（一般に、相対パスと絶対パスを同じ::開始することは、何度も苦痛の原因になっていますが、それは真実です。）

私が知らないことの1つは、 @fooが最高かどうかです。 私がうまくいくと思う、そして私が考えた他のオプションは[]です：

• [std]::collectionsと[crate]::collections // []::collectionsは奇妙すぎるようです。

パスのためだけに新しいシジルを導入するべきではないと私は本当に思います。 一流の強制::で::crate::fooアドレス@glaebhoerlさんのコメントに十分であると解析をあいまいさを排除します。 また、 crate::の意図されたメンタルモデルにより密接に適合します。これは、 self::ようなパスプレフィックスではなく、現在のクレートの名前の代用です。

（一般に、相対パスと絶対パスを同じ::開始することは、何度も苦痛の原因になっていますが、それは真実です。）

これが何を意味するのかわかりません。 ::で始まる相対パスはないと思いますか？

@nikomatsakis @glaebhoerl私があなたの提案が好きかどうかに関係なく（私は実際には両方と一緒に暮らすことができます）、RFCに固執してもらえますか？ それは多くの方法で前後に議論されてきました、そして私は再び議論を開くことが誰にも役立つとは思いません。 合計82人が最新のRFCのスレッドにコメントし（以前はかなりの議論がありました）、多くの人がそれについて非常に強く感じています。 変更を検討する機会を与えずに、この時点で提案の土壇場での変更をこっそりと行うことは、彼らにとって不公平だと思います。
特に、＃44721 @nikomatsakisで、「実装についてのみ話しましょう」という引数で機能に関する議論をシャットダウンしたため、少し混乱しています。

@表記と[]表記の両方が提案されていますが（私は両方のサポーターです）、ユーザーからの否定的な反応のために、少なくともそれは私の印象ではありませんでした。 。

先頭の::が、先行する識別子で始まり、内部に::があるパスと混同される可能性がまったくない場合でも、視覚的にはあまり明確ではありません。

また、それはあまり示唆的ではありません。 @はより良いニーモニックです。 先頭に::場合、先頭にある/ルートを意味するファイル名パスに似ているのか（Unixyシステムを使用している場合）、それとも先頭にない標準の省略形になっているのか疑問に思う必要があります。 「相対的な名前なので、名前を省略した」という意味です。 少し考えてみると、前者の方が理にかなっていることがわかりますが、要点は少し考えてみるということです。 @ （またはそのようなもの）は、コンパイラーとコーダーの両方で即座に区別できるため、何が起こっているのかを即座に把握しやすくなります。

先頭の@は、先頭の::よりもどのように区別し::は、RustとC ++の両方ですでに確立されたメカニズムです。

@ rpjohnst-私はあなたが応答しているまさにその文の中でどのように言ったか！ @は視覚的に区別されます。 拡張するには：それはあなたに飛び出します。 トークンストリームのメンタルモデルで、リーディングと内部のポジショニングが混同される危険はありません。

@はまったく新しいトークンであり、まったく意味がなく、理解するには「一瞬の思考」よりもはるかに多くの時間がかかります。 先行する::を内部の::と混同することは、そもそも問題ではありません。先行する::は相対パスである可能性があります。

@rpjohnst - ::意味について十分なトレーニングを受けていれば、あなたの発言は真実です（C ++またはRustの経験によって提供されます）。 私は学習可能性と本質的な違いについて話していました。 「異なるコンテキストで使用される同じシンボル」は、「一意のシンボル」ほど区別できるものにはなりません。

@を、許容できる代替案があるこのようなユースケースの一意のシンボルとして燃やす価値はないという議論を受け入れることができます。

@Ichoran ：特定のセマンティクス（ @ ）の新しいトークンをRust文法に追加することは、軽視するステップではないと思います。 @ nikomatsakisでそれを行うのに近すぎるのではないかと少し疑っています。と他の人の提案。 1つは、言語の寿命の後半で別の目的に再利用できないためです（パスがコード内で非常に普及しているため、 @トークンが多くの場所に表示される可能性があります）。 また、Rustコードの複雑さの認識にどのような影響があるのだろうか。 たとえばC ++に慣れていない初心者にとって、Rustは非常にバロック的で威圧的な表記の言語であると私は信じています（ただし、これに関する研究はありません）。 今年の戦略目標の1つは、学習可能性を最適化することであり、Rustの親しみやすさを推測します。 したがって、 @空想するときは、コードで目立つという直感があるため、これを考慮する必要があるかもしれません（ @rpjohnstは当然の質問だと思います）。 私はこれで何を意味するのか十分に明確ですか？

（私が主張したことは何でも自由に訂正または明確化してください。なぜなら、私はRust文法に関する議論にそれほど厳密に従う時間がないからです。）

@ est31

私があなたの提案が好きかどうかに関係なく（私は実際には両方と一緒に暮らすことができます）、RFCに固執できますか？

基本的に同意します。 私は今、大きな議論に参加したくありません-結局のところ、それは暗黙の期間です！ -しかし、私は@アイデアを「そこに」置いて、バックグラウンドで煮込んでいたかったのです。 物忘れがちなこともあり、書き出すことで後で思い出すことができます。

私の考えでは、この時点で行うべき正しいことは次のとおりです。

• 記述されたとおりにRFCを実装します。
  
  
  
  • 私たちは、例えば、のの提案@rpjohnst採用することをお勧めします::crate 、それは非常に小さいデルタのように思えるので、ちょうど解析disambiguityを解決するために、絶対パスのために、そして実際に全体の一貫性を向上させます。
  
  
• 使用経験を積んでください。
• その間に浮かんできた代替案を念頭に置いて設計を再検討し、最終的な安定化の決定を行います。

これは私がコメントを書くつもりだった精神でしたが、私はそれを明確にしなかったと思います。 おそらく、それをプライベートファイルに保存する方が良かったでしょう。 ：woman_shrugging：

編集：また、 @と[]が以前に調達されたことを知っていますが、 @::foo表記が現在の相対的なものとして以前に言及されたかどうかは思い出せません木枠。 だから私はそのアイデアの著者であると主張するつもりはありません。

OTOH、私が言及したアイデアは以前に提起されたものではなく、RFCを拡張したものではありません。 また、「絶対パスの最終的な構文。さまざまなオプションを実際に試すことができるコンテキストで、ここで実行するバイクシェディングがさらにあります。」 問題の本文に未解決の質問として明示的にリストされています。 一般に、受け入れられたRFCの再訴訟を避けるように努めるべきであることに同意しますが、この状況は、たとえば包括的範囲での状況に匹敵するとは思いません（ugh）。

このディスカッションスレッドも参照してください。

https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678

グレートモジュールアドベンチャーの別のエピソードへようこそ！ 私たちが最後に会ったとき、私たちの勇敢な冒険家たちは、RFC＃2126を受け入れて、ついに伝説の土地にやって来ました。 そこで彼らは短い休息を取り、Impl期間から始める準備をしました。 その間、大変な作業が行われ、実際にモジュールシステムの概要が実装されるようになりました。 しかし、まだ解決すべきいくつかのやっかいな質問がありました…そしてそれは私たちをこのディスカッションスレッドに導きます。

花の少ない言語で：実装期間中に、「パスと可視性を明確にして合理化する」RFC（および関連する多くのRFC）の実装で多くの進歩を遂げました。 実際、私たちはほとんど進歩しすぎていました。いくつかの異なるバリアントを実装しました。私たちが本当に望んでいることについて話し合いを始めたいと思います。

いつかこの素晴らしい作品を安定させたいと思っています=）そしてそれは私たちが変種の1つを選ぶことを要求するでしょう...それ故にスレッド。

個人的には、@ nikomatsakisが言及している@構文のファンです。 それは簡潔で、合理的に自明です。 私たちは、ここに新しい構文の導入いくつかの並べ替えを持っているような予約名よりもとても良く、特殊な文字つもりだcrate （ぐふ）を。

特にhttps://github.com/rust-lang/cargo/issues/1311が解決されたことを考えると、2番目の外側のポインターに取り組む立場にあるようです（実際にはすでに閉じているはずです）。 少しの指導と、 @とcrate構文の決定で、これに取り組むことができるかもしれません。 考え？

実装されていない2つのlintの追跡の問題を追加しました。

小さな互換性の問題があることに気づきました。 extern crate暗黙的にする場合、その作業を行う際に重大な変更が必要になります。 extern crateは、クレートを強制的にリンクします。 これは、Cargo.tomlで追加のクレートを指定したが、正しくリンクされていないlib.rsを指定しない場合にエラーを引き起こす可能性があります（たとえば、panic = unwindクレートとpanic = abort、または同じシンボルをエクスポートするクレート）。 これは問題のない破損であると判断しましたか？

小さな互換性の問題があることに気づきました。外部クレートを暗黙的にする場合、その作業を行う際に重大な変更が発生します。外部クレートはクレートを強制的にリンクします。 これは、Cargo.tomlで追加のクレートを指定したが、正しくリンクされていないlib.rsを指定しない場合にエラーを引き起こす可能性があります（たとえば、panic = unwindクレートとpanic = abort、または同じシンボルをエクスポートするクレート）。 これは問題のない破損であると判断しましたか？

これまで私が見た唯一の解決策は、クレートから何かをインポートするときに、クレートを暗黙的にリンクすることだけですが、これにはまだいくつかの問題があります。 特定のネイティブライブラリにリンクしたり、 #[no_mangle]シンボルをエクスポートしてネイティブライブラリの依存関係を解決したりするなど、インポートする錆のシンボルを単にエクスポートする以外の方法で、クレートが機能を公開する方法はたくさんあります。 extern crateが削除されたら、そのようなクレートを強制的にリンクさせる唯一の方法は、必要に応じてインポートするプラセボラストシンボルをエクスポートすることです。 extern crateに固執するので

ええ、Firefoxではこのパターンを明示的に使用しています-リンクする必要があるクレートのextern crateステートメントを含むトップレベルのgkrustクレートがあります（これらはFirefoxが呼び出すRustで記述されたextern C関数を公開します）

これを強制するためにlib.rsでuse cratename;を要求することでそれを機能させることができます。

この目的のために#![link_crates(stylo,webrender)]属性を持つのはどうですか？ extern crateとは異なり、名前ツリーにクレートは追加されません。 新しい名前を付けると、リンク用のクレートのみを含め、ステートメントを削除してはならず、 extern crateを削除する必要があることを読者に明確に示します。

それは反対の問題を解決しますか？

ああ、そうですね、2015年のエポックの人々にとっては、エポックを切り替えることなくコードをアップグレードできます。

ただし、これは、_全員_がlink_cratesキーを使用する必要があることを意味します。 それは理想的ではありません。

この目的のために＃！[link_crates（stylo、webrender）]属性を持つのはどうですか？ externクレートとは異なり、名前ツリーにクレートを追加しません。

リンクのみのクレート、Rustシンボルの付いたクレート、またはその両方として使用できるクレートはどうですか？

@whitequarkこれらのクレートのシンボルを使用すると、現在のように無料でリンクを取得できます。 属性は使用サイトにあるため、ユーザーがクレートの使用方法を決定します。

@Manishearth

ただし、これは、全員がlink_cratesキーを使用する必要があることを意味します。 それは理想的ではありません。

いいえ、私は自分の提案を十分に表現していません。 use cratename::item;がlink_cratesと同じ効果を持つ部分をそのままにしておきたい。 link_crates機能は、クレートからのアイテムは必要ないが、リンクは必要な場合にのみ使用する必要があります。 クレートからアイテムをインポートすると、RFCが提案したようなリンクが得られます。

その目的のためにコードにuse cratename;を含めることは、lintと（最も重要な）コードリーダー/ライターを混乱させるため、良いとは思いません。したがって、その正当なものに専用の機能が必要だと思います。 （ただし、めったにありません）ユースケース。

@ est31 link_cratesの構文について、属性として使用する代わりに、 extern crate foo;ようなことをしてみませんか？

@ retep998
良いアイデア！ ：笑顔：
https://github.com/rust-lang/rfcs/pull/2166は、リンクのみのクレートのスコープ/モジュールにクレートの名前を持ち込まないようにするために、 extern crate foo as _;を導入しました。

@ est31 link_cratesの構文に関するバイクシェディングでは、属性として使用する代わりに、extern crate foo;のようなことをしてみませんか？

ただし、重要なのは、長期的にはextern crate構文を取り除くことです。

@alexregポイントは、一般的なケースでは不要にすることです。 これは、完全に根絶する必要があるという意味ではありません。おそらく、Rustアイテムを使用せずにリンクする必要がある、クレートのエッジケースの優れたソリューションである可能性があります。 （とにかく、コンパイラが古いエポックをサポートしている限り、それは存続します。）

@SimonSapinしかし、先に進むと、それがエッジケースになる場合は、おそらく特別な構文を使用することは意味がなく、属性（上記で提案したように）の方が意味があります。

ここではまだuse fooまたはuse foo as _で十分だと思います

@Manishearthに同意します。

extern crate;に関する私の見解を要約すると：

利点：

• extern crateは、ライブラリの一番上にある使用済みの木枠の包括的なリストを提供します。 そこCargo.tomlですが、例を持っている場合、それはあなたにインポートする木枠のリストを与えると、これは非常に有用であるとして、今、通常の木箱で、これはその関係ありません。 考えてみてください。例で開発依存関係のサブセットをインポートした場合はどうでしょうか。 これは、新しいクレートのAPIを理解しようとするときに高いメリットがあります。これは、学習可能性のメリットとも呼ばれます。 一方、 extern crateは木枠のどこにでも表示される可能性があるため、リストを網羅する必要はありませんが、たとえば、これはあまり関連性がありません。 必要に応じて、外部クレートをクレートルートでのみ機能するようにいつでも変更できます。

短所：

• extern crateは、クレートを追加するときに入力するものが増えることを意味するため、小さな煩わしさです。 これが多くの人がextern crate反対している理由だと思いますが、私にとってはそれがやる気を起こさせる理由ではありません。
• extern crateは取引の一部であると思います。 extern crateを放棄しますが、独自のクレートからのインポートと実行中のクレートからのインポートを区別できます。 これははるかに便利な機能であり、コード例/テストでの学習可能性の欠点をIMOよりも上回ります。 これが、私がextern crate削除に同意する動機付けの理由です。

extern crateは、ライブラリの最上部にある使用済みクレートの包括的なリストを提供します。 通常のクレートでは、Cargo.tomlがあるため、これはそれほど重要ではありませんが、例がある場合は、インポートするクレートのリストが表示されるため、これは非常に便利です。

これがここでの議論にどのように関連しているかわかりません。 これは、すでにマージされているRFCに対するポイントです。

@Manishearth私はここで@ retep998にもっと返信していました。 いいえ、ポイントは、すでにマージされたRFCに反しているという理由だけで、違法または無関係ではありません。 決定の長所と短所を反映し、知る必要があります。 たとえば、 lib.rsから外部クレートを削除することはできますが、人間工学と学習性の利点のために（作成者ではなく、ライブラリのユーザーのために） hello_world.rsままにしておきます。

（あなたが返信するPeterのコメントで）議論されているのはリンクのみのクレートであるため、これは無関係です。 これは、「すべての外部クレートを一番上にリストする」というニッチなユースケースであり、わずかなメリットです。 特に、リンクのみのクレートではない依存関係がある場合（これはFirefoxには当てはまりませんでしたが、現在は当てはまります）。

暗黙の外部クレートをテストに適用しないことについてのより一般的なポイント（特にリンクのみのクレートについてではない）の場合、それは興味深いポイントですが、それはもっと多くなるので、私は本当に同意しませんコードの半分だけで使用されていると混乱します。

ですから、私が間違っていなければ、ここに残っている唯一の実装ポイントは＃48719です。 今それに取り組んでいる人はいますか？ そうでなければ、私は行くことができます、私は推測します...

はい、＃50260で試してみます

土、2018年4月28日には、9：15 AMアレクサンダーRegueiro [email protected]
書きました：

ですから、私が間違っていなければ、ここに残っている唯一の実装ポイントは

48719https ：//github.com/rust-lang/rust/issues/48719 。 誰か

今それに取り組んでいますか？ そうでなければ、私は行くことができます、私は推測します...

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/44660#issuecomment-385187379 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABivSMyg6L4nQ1O7nMcvY4JCGjWKRiq3ks5ttJWhgaJpZM4PaPWi
。

48722が完了しました。 @ManishearthはOPを更新して

@ mark-im @Manishearth https://github.com/rust-lang/cargo/issues/1311も完了しているので、そのポイントをチェックボックスに変更してチェックする価値があるかもしれません。 でも気になるのですが、Cargoを使わないときのアプローチはどうなっているのでしょうか？ （誰もが貨物を避けているわけではありません...）

@alexreg Cargoがrustcにクレートの名前を変更するように指示するために使用するメカニズムは、貨物を使用していない人にも同様にアクセスできます： --extern name_rustc_sees=path_to_dep.rlib 。

実際、 https：//github.com/rust-lang/rust/pull/47992がリリースされた時点で、実装段階全体がまもなく終了するようです。 私は何かが足りないのですか？ やるべきことが残っている場合は、これを進めるのを手伝ってください。

ええ、それは途中です。 私はそれをまとめる必要があります
次の週。

木、2018年5月3日には、午前7時51分PMアレクサンダーRegueiro [email protected]
書きました：

実装段階全体がまもなく終了するようです–いつ

実際、47992https ：//github.com/rust-lang/rust/pull/47992が着陸し

何か足りない？ 少しでもあれば、これを進めるのを手伝って幸せです
やるべきボブが残っています。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/44660#issuecomment-386494018 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABivSDYFonDWvxZEdxWXoykroaL2mJPxks5tu8I_gaJpZM4PaPWi
。

@Manishearth良いもの。

@aturonとhttps://github.com/rust-lang/rust/pull/50260が着陸しましたが、すべて実装されていますか？

RFCの後に提案された計画へのリンクを誰かが手に入れましたか？ 実際に実装されたものにより近いものですか？ （ --externクレートのインポートがプレリュードに追加される場合など）

見つけた： https ：

これは非常に重要な変更であるため、RFCを更新する必要がありますか？

通常、RFCは更新されません。 それらは最終的な仕様ではありません。 彼らは
コンセンサス構築ツール。

2018年6月18日月曜日午後9時43分、誰ですか？ 自分？！ [email protected]は次のように書いています：

これは非常に重要な変更であるため、RFCを更新する必要がありますか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/44660#issuecomment-398247665 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABsij-Iwwb7vf4qBrsq9KFFqhuIbkVBks5t-Fc3gaJpZM4PaPWi
。

@ mark-imその談話の投稿はRFCの精神の中にとどまります。 RFCの要約をその投稿と比較してください。詳細はほとんどありませんが、ほとんど同じです。 チームがまったく異なる変更を行うことを決定したRFCがありましたが、これはそれらの1つではありません。

それはすべて真実ですが、すべてが1か所にあるといいでしょう。 私はそのロジスティックの課題を理解していますが...

🔔🔔 2018年初頭の

@aturon最後の更新、およびモジュール作業グループの最後の会議の結果、 https： //internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205が作成され、具体的には「 2つのバリエーションを持つ単一のコア提案に絞り込みました。」 私の知る限り、それはまだ真実でした。 両方の実験をサポートするために、毎晩、フィーチャートグルを介して両方を実装したという印象を受けました。

エディションは2つのバリアントのいずれかを選択し、機能フラグなしでサポートすることを選択し、エディションガイドに文書化したようです。 それはどこで議論されましたか？ 私の知る限り、モジュールワーキンググループもlangチームもそこに関与していなかったからです。

2018プレビューから構築された新しい提案については、 https：//internals.rust-lang.org/t/relative-paths-in-rust-2018/7883を参照してuseステートメントとコード内のパスの直接使用の両方で同じ名前解決を使用します。

こんにちは、 ::some::pathとcrate::some::pathセントだけです。主に、平易な英語として読みやすく、左にぶら下がっている句読点を残さないため、後者の方が好きです。

ご覧になり、ここにフィードバックを残してください！

これがあなたの意図したことだといいのですが。 すべてのpub(crate)がcrateに変更された先物クレートへの大きな変更を確認した後、インポートと可視性の両方でcrateを使用することを確信しています。モディファイアは不自然で紛らわしいと感じます。

crate enum Either<T, U> {
    A(T),
    B(U),
}

2つを一緒に使用すると、特に混乱します。

crate use crate::foo;

私たち全員を切り替えさせようとするlintの問題で述べたように、それは私を非常に悲しくさせます。おそらく、サードパーティのlintを実装して、私が維持しているライブラリで使用するために、反対のことをしたいと思います。 pub(crate)をcrate変換することから。

（注：一貫性を保つために適切と思われる変更の他の部分についてはコメントしていません。 pub(crate)からプレーンなcrateへの変更のみです。）

@seanmonstar次のエディションのプレビューでモジュールシステムに追加の変更が提案されているため、 crate::fooはさらに少なくなると予想しており、 crate use crate::は特にまれにしか発生しないようです。

2018年の最初のプレビューのモジュールシステムでは、クレートのより深い参照に対してもcrate::を書き込む必要があります。 提案されたモジュールシステムでは、あなただけの必要があると思いますcrate:: （例えば、foo.rsからlib.rsに、またはFOO / bar.rsからfoo.rsに）あなたのクレート内の参照アップのために、しかし、ないあなたのクレートでダウン参照のための（例えば、lib.rsからfoo.rsに、またはfoo.rsからのfoo / bar.rsまで）。 そして、一般的に、再エクスポート（ pub useまたはcrate useを介して）は、より高いレベルのモジュールのより深いモジュールから何かを再エクスポートすることを期待しますが、その逆ではありません。

したがって、一般的に、 crate use crate::foo;を見て驚かれることでしょう。

それでも、私が取り組んでいるプロジェクトでは、まさにこのシナリオがあります。 いくつかの「一般的な」ヘルパーを含むモジュールがあり、次に基本特性とコンビネーターを定義する別のモジュールがあります。これらはいくつかの一般的なヘルパーを使用しているため、他の部分で自分自身を助けるために再エクスポートします。クレート：

現在：

// in filter/mod.rs
pub(crate) use ::generic::{Combine, Func};

// in filters/foo.rs
use ::filter::{Filter, Func};

lintは、これを次のように変更するように要求します。

// in filter/mod.rs
crate use crate::generic::{Combine, Func};

だから、私は誰も出会うことのない仮説を考え出そうとしていませんでした。 本物だ。

@seanmonstarに完全に同意します。 必要がない限り、このキーワードをオーバーロードしないでください（オーバーロードしません）。

ええ、あなたは正しいですが、再輸出は_通常_バブルアップしますが、ショーンが概説しているように、_横方向に再輸出されることも重要です。 ファイルが非常にうまく分割されているので、これはサーボメディアクレートに対しても検討していることですが、これは、すべてのノード実装で多くの一般的なインポートを意味します。

モジュールで何が使用されているかを宣言し続けることは可能であり、おそらくクレート属性として明示的に使用する必要がありますか？ ソースファイルを見て、その範囲内にあるものを知ることができるようにしたいと思います。 ソースファイルの先頭にルートレベルのインポートを数行含めると、スコープ内にすべての外部依存関係を暗黙的に含めるのではなく、ソースファイル内で実際に行われていることのコンテキストを提供するのに役立ち、リファクタリング時に非常に役立ちます。

私の箱の1つで変換を試したので、これについて話しているのを見た他の人のように、 pub(crate)代わりにcrateを可視性修飾子として使用することに確信が持てません。改善。 ここでの私の推論は、クレートモニカが非常に広く使用されており、アイテムの前に貼り付けるだけで少し厄介になるということです（Javaのpublic static void main()などの一部の言語で得られるキーワードスープを思い出させます-少なくともRustの最後にはリターンタイプがあります）。 pub(crate) 、少なくともpubを保持して、 crateがこのコンテキストでの可視性を扱っていることをより明確にします。

これは、可視性修飾子とパスの両方でcrateキーワードを組み合わせた、私が遭遇した別のインスタンスです。これは、 crate use crate...インスタンスよりもさらに可能性が高いようです。

電流：

pub(crate) struct Bar {
    pub(crate) foo: ::Foo,
}

pub(crate) struct Baz(pub(crate) ::Foo);

この追跡の問題からの変更：

crate struct Bar {
    crate foo: crate::Foo,
}

crate struct Baz(crate crate::Foo);

私は個人的に、新しいものが現在の方法よりも混乱していると感じています。

pub(crate)をcrateに変換するためにRFCを最初に読んだとき、それは簡単に聞こえると思いました。 pub(crate)は、この領域の関連するRust構文の残りの部分と比較して非常に奇妙に見えます。

しかし...

後少しピストンゲームを変換錆2018にし、それを最初に手を見て、私はsおよび他のコメント」@seanmonstarに同情的だ認めなければならないこと持つ裸crateどこでも振りかけ認知耳障りました。 時間が経つにつれて自然にこれに慣れるかどうかはわかりません。

他の人が言っているように、キーワードは両方の文脈で非常に異なる何かを意味して感じます。

use crate::menu::{Sound, Volume};

crate mod color;

...

/// A type for storing text and an associated color it should
/// be drawn as.
crate struct ColoredText {
    crate color: types::Color,
    crate text: &'static str,
}

この提案の残りの部分（モジュールシステムの更新）が本当に好きであることを明確にしたいと思います。

pub(crate)は少し手間がかかり、奇妙に思えますが、裸のcrateも少し違和感を覚えます。

crateを再利用する代わりに、ここで別のキーワードを検討できますか？

@ neon64提案されたinternalは妥当に聞こえますが、他にもある可能性があります。 Rust 2018でキーワードを追加できるので、これを検討する機会があります。

internalは私にはpub(crate)より重いようです。 短くはなく、新しいキーワードです。

intどうですか？ ：P

内部（ ins ）、内部（ int ）、保護（ pro ）、ローカル（ loc ）、秘密（ sec ）、内側（ inn ） crateキーワードに代わるものはたくさんあります。

しかし、 intはC / C ++開発者を混乱させるでしょうか？ （整数キーワード）

プログラマーとして、あなたがパブを見るとき、あなたはそれをパブリックとして扱います、あなたが別の可視性レベルを導入したいなら、あなたはそれが一貫性を保つために形容詞である必要があります。 私が覚えている限り、パブは最初は公開の略であり、どちらの場合もパブ（クレート）はより自然に感じます。 クレートはそのための奇妙なキーワードです。
pub（crate）はそのままにするか、形容詞の略語を追加したほうがいいと思います。

また、名前付けの難しさは、パブが略語であるという事実にあると思います。それが公開されていれば、プライベートまたは内部と呼んで忘れても問題ないと思います。

個人的には、 pub(crate)の問題は見当たりません。 構文は一見明確で明確であり、実際のRustと一致しています。 これを頻繁に入力する必要はないので、5回の余分なキーストロークが問題になると思います。

@UtherII

pub(crate)短縮名が必要な理由は、現在使用されているpub多く（おそらくほとんど）がそれに置き換えられるためです。

Rust 2018では、効果的にプライベートアイテムにpubを使用すると（プライベートモジュールに表示されるため）、警告が表示されます。 代わりに、そのようなアイテムにはpub(crate)を使用する必要があります。 この規則により、コードの可読性が向上します。アイテムがpubとマークされている場合にのみ、他のクレートに表示されますが、現在、他のクレートに表示されているかどうかは一目でわかりません。

申し訳ありませんが、このスレッドに返信するのではなく、誤って新しい問題を作成しました。 おっと、私はgithubにかなり慣れていないので、ボタンをクリックするだけで、ここで応答していると思っていたものにサインインしましたが、実際には新しい問題が発生していました。 新しい号に書いたものをここに貼り付けます。新しい号は削除できます。申し訳ありません。

版のマニュアルが人々がここにフィードバックを残すことを提案したので、私はそうすることに決めました。

クレートルートから要素にアクセスするために、crate ::または::のどちらでもかまいません。 ::はすでに構文になっているので、crate ::と::の両方を使用できる場合は、両方を使用する必要があると思います。 私の見方では、パスに関して新しく提案されたクレートシステムは、基本的に古い構文と同等ですが、唯一の違いは、externキーワードを使用する必要がなくなり、明示的に使用するよりもアクセスしやすくなることです。サブモジュールでは、基本的にどこにでも暗黙的にインポートされます。

他の唯一の追加は、クレートルートを::ではなくcrate ::で開始することです。 これは私が最初に学んだ方法と一致しているので、::だけで始めるのが好きですが、モジュールシステムをまだ学んでいない人でも、crate ::で始める方が直感的です。 なぜ両方の構文形式を許可しないのですか？ 両方を持つことが不可能になる理由はありますか？ 両方をサポートできる場合は、両方をサポートすることを強くお勧めします。 1つしかサポートできない場合は、::に慣れているのと同じように、初心者の方がクレート::として習得しやすいかもしれませんが、::の理解を簡単に更新できます。そうなるために、おそらく私の動機は利己的です。

だから本質的に、私は最終的にはあまり気にしませんが、個人的には::を好みますが、どちらかを選択する必要があり、crate ::から始めることが初心者にとって優れていると人々が考える場合は、両方をサポートするのが理想的だと思います。これに反対しないでください。

#[path]はRust 2018でネストされたモジュールでどのように機能することになっていますか？ （https://github.com/rust-lang/rust/issues/35016#issuecomment-409185342）

IIUC、現在、2つのファイルsrc/lib.rsとsrc/bar.rsが与えられた場合、次のように置き換えることができるXはありません。

mod foo {
    #[path = "X/bar.rs"]
    mod bar;
}

bar.rsへのパスは常にsrc/foo/X/bar.rsであるため、モジュールbar.rsが検出されます。これは、ディレクトリfooが存在しないため無効です。

私たちはpub(crate)交換に適した名前でバイクシェッドを行っており、コアチームはまだフィードバックを求めているので、私の経験を共有し、提案を提供したいと思います。

私が書いたある木枠の中で、どこでもpub(crate)入力するのpub短縮し、クレートの外に表示する必要のない多くのシンボルを誤ってエクスポートしました。 おっとっと。 😛（私の特定のケースでは、クレートは内部にあり、公開されていないため、実際には問題ではありませんが、それでも！正確さよりも便利です。）そうです、クレートレベルの可視性を伝えるには、2つのキーワードのマッシュアップよりも優れたものが必要だと強く信じています。

しかし、 crateがそのキーワードとして適切であるとは思いません（このトピックに関する他の人からのフィードバックについては上記を参照してください）。他の提案されたキーワードは、問題に視点からアプローチすることで、ポイントを逃しているように感じます。木枠の根の; 問題は、モジュールの観点、つまりキーワードを含む特定のコード行にあります。 つまり、コードは「クレートの局所性」を提供しようとしているのではなく、定義されているモジュールから参照をエクスポートしようとしています。

その意味で、私はキーワードexport好きです（ externと混同する可能性があるとしても、 extern crateが死んでいるので、それは意味がありませんか？） export struct Foo;非常に読みやすく、他のいくつかの言語（ish）と連携しています。 このRFCまたは他の場所で、キーワードとしてexport言及を見つけることができませんでした。 ですから、それもあります。

完全を期すために、 @ seanmonstar 、 @ johnthagenなどによって提起されたユースケースをカバーしています。

export use crate::generic::{Combine, Func};

// Or even better using relative paths
export use ::generic::{Combine, Func};

export struct Bar {
    export foo: crate::Foo,
}

export struct Baz(export crate::Foo);

use crate::menu::{Sound, Volume};

export mod color;

// ...

/// A type for storing text and an associated color it should
/// be drawn as.
export struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

そうは言っても、私はpub(crate)を火で殺すことに賛成です。 私もcrate 、FWIWが好きです。

@parasyte export見られる問題は、「このクレートは____をpub目的です）と混同される可能性があることですが、あなたがどのように主張しているのかはわかります別の視点。

ほとんどの人がpub(crate)は理想的ではないことに同意しているようです。多くの人が、現在他のコンテキストで使用されている名詞キーワードcrateが代わりに不快感を与える可能性があるという懸念を表明しています。 他の（潜在的に新しい）キーワードを十分に検討したことを確認することは、Rust 2018がこれを決定する前に、非常に良い時間の使い方のように思われます。

しかし、これがまだ議論の余地がある場合、私は「公式の」フィードバックを聞いたことがありませんか？

@parasyteの提案に沿ってさらにいくつかの単語を紹介するために（ exportはpub(crate)よりもpubように見えるという@johnthagenに同意し

shared use ::generic::{Combine, Func};
shared struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

global use ::generic::{Combine, Func};
global struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

Javaの足跡をたどって、 protectedようなものを使用することもlocal （crate-localの意味で）もありますが、 globalは実際には混乱する可能性が低いと思います（たとえば、 localは_file_-localである可能性があります）。

人々はpub(cr)あるいは単にcrどう思いますか？

crateは、見過ごすには良すぎるようです。 これはすでにキーワードであり、 extern crate以前の使用はなくなります。 他の用途はすでに可視性pub(crate)関連しています。

形容詞としてクレートを使用して少し目を細めても、それほど戸惑うことはありません。 「家」などの単語は形容詞としてうまく使用できます。 IANAEnglishProfessor。

木枠の目に見えるアイテムを再エクスポートすることはそれほど問題ではないと思います。 個人的には、それを定義するモジュールの直接の親でアイテムを再エクスポートしたことがあります。つまり、（おそらく） self代わりにcrate selfを使用したいということです（seanmonstarのコード編成の場合にもかかわらず） ）。 例えば。

    mod detail {
        crate struct Foo;
    }

    crate use self::detail::Foo;

型への絶対パスと組み合わせた可視性としてクレートを使用すると（ここでもseanmonstarの例を使用）、 pub(crate) struct Foo(pub(crate) ::Foo);ではなくcrate struct Foo(crate crate::Bar);ように見えます。 私の唯一の希望は、この構成が人気がなく、したがって移行してもこのクレートスープが作成されないことです。 ユーザーは、明示的にインポートすることでこれを回避できます。

use crate::Bar;

crate struct Foo(crate Bar);

私はshareまたはそのようなものの提案が好きです。 give 、 provide 、 deliver 、 offer 、 serve 、 post 、 forward .. 。形容詞でなければならない場合は、これらすべてに接尾辞を付けて変換できます： shared 、 givable 、 providableなど。

少しの間JavaScriptを選択するために、ES6には、言語に組み込まれたパッケージとモジュールの概念すらありません。 モジュールしかありません。 ES6のexportキーワードは、常にモジュールから参照をエクスポートします。 それを使用したい場合は、パスによる参照をimportする別のモジュール次第です。

これは大きく異なるではありませんpubとuseそれぞれ。 exportキーワードを使用すると、混乱が生じると思います。 pub(crate)は実際には一種のニッチです。 これが、過去にpubを使用することを選択した理由です。 ;（

crate可視性修飾子の問題は、＃53120に抽出されました。 さらなる議論と決定はあちらで続けられるべきです。

mod.rs変更の問題は、＃53125に抽出されました。 さらなる議論と決定はあちらで続けられるべきです。

extern crate非推奨の問題、およびuse crate_name::fooとcrate_name::foo JustWork™の問題は、 https：//github.com/rust-lang/rust/に抽出されました

モジュールパスシステムの選択の問題は、 https：//github.com/rust-lang/rust/issues/53130に抽出されてい

この問題からすべてのビットを別々の問題に抽出しました。 これで締めくくります。

@Centril ： https ： //doc.rust-lang.org/unstable-book/print.html#extern_preludeリンクはこちら。 これはどこで議論されていますか？ この情報が実際に欠落している場合は、OPに追加できますか？

@ sanmai-NL「externprelude」が何であったかについて私の記憶をリフレッシュできますか？

use some_crate::foo::bar;を実行する機能だけの場合は、 https：//github.com/rust-lang/rust/issues/53128になり

その一部はhttps://github.com/rust-lang/rust/issues/54230で議論されてい

@ sanmai-NL問題は主に診断にあると思います。

extern_preludeあるcrate_name::foo::barの外use （インポート）経路。

@Centril

「エクスターンプレリュード」とは何かについて、私の記憶をリフレッシュしていただけませんか？

一般に、「プレリュード」は現在、クレート全体のスコープ内にあり、特定のモジュールに接続されていないすべての名前に使用されています。 （実際にはたくさんあります。）

@petrochenkovでは、それに関連する「

@alexreg
--extern渡されたクレートは、特定のモジュールに接続されていない間、クレート全体のスコープに含まれます。

これらの情報の塊が、どんなに不安定であっても、公式のドキュメントソースに記録されていれば素晴らしいと思います。 Esp。 不安定な本のように、概念の外部の言及がある場合。 ただし、これらの概念を実装するメンテナがそうすべきだと言っているのではありません。

@petrochenkovありがとう、理にかなっています。

この問題からすべてのビットを別々の問題に抽出しました。 これで締めくくります。

@Centril現在のベータ版の問題の追跡リンクはこちら。 人々がコメントを洞窟探検する必要がないように、元のコメントを最新の情報で更新しますか？