Rust: RFC 1937の追跡の問題：`main`の`？`

終了ステータスはどのように処理されますか？

@Screwtapelloによるこのコメントは、FCPの終わりに近すぎて、それに応じてRFCに変更を加えることができないようです。

要するに、RFCは、十分な根拠はあるものの、あいまいでわずかに異常な結果をもたらすという理由で失敗した場合に2を返すことを提案しています。 最も驚くべきことは、プログラムが成功または失敗以外の詳細を必要としていることを示さない場合に1を返すことです。 これは、RFCプロセスを混乱させているように感じることなく議論できるほど十分にバイクシェディですか、それともこの特定の実装の詳細に縛られていますか？

ただし、実装の詳細ではありませんね。

一部のスクリプトは、サブプロセスから情報を取得する方法として終了コードを使用します。

これは特に、サブプロセス（Rustで実装）に、バイナリの「すべてが正常」/「問題が発生した」以外に提供する情報がない場合に関するものです。

一部のスクリプトは、サブプロセスから情報を取得する方法として終了コードを使用します。

その動作は、ゼロ以外の場合は失敗を意味するという点で、常に_except_と呼ばれるプログラムに大きく依存します。 main関数ラッパーとルックアップテーブルを備えたstd::process::exitが、何が行われたとしても、より明確な終了ステータスが必要な場合に最適なオプションであり続けることを考えると、これはほとんど重要ではないように思われます。

ただし、SemVerには「ほとんど重要でない詳細」の例外はないと思います。

未解決の質問リストに終了コードを追加する必要があると思います。 @zackwは、関連する内部スレッドも開きました。

多くの人は、失敗時に終了コードを1にする必要があることに同意します（ 2ではなく）。
https://www.reddit.com/r/rust/comments/6nxg6t/the_rfc_using_in_main_just_got_merged/

@ arielb1このRFCを実装しますか？

@bkchr

いいえ、それを指導するだけです。 メンタリングノートを書くのを忘れないように割り当てました。

ああいい、私はそれをすることに興味があるでしょう:)
しかし、どこから始めればいいのかわかりません：D

@bkchr

それが私がここにいる理由です:-)。 メンタリングの指示はすぐに書く必要があります。

さて、私はあなたの指示を待っています。

メンタリングの手順

これは[WG-compiler-middle]の問題です。 ヘルプが必要な場合は、irc.mozilla.org（私はarielby）またはhttps://gitter.im/rust-impl-period/WG-compiler-middle （私は@ arielb1 ）の#rustcに参加できます。そこの）。

＃44505にWIPコンパイラのreadmeがあります-コンパイラのいくつかのことを説明しています。

このRFCの作業計画：

• []- Termination lang-itemをlibcoreに追加します
• []- mainで$ Terminationの使用を許可する
• []-doctestsでTerminationの使用を許可する
• []- #[test]でTerminationの使用を許可する

Termination lang-itemをlibcoreに追加します

まず、いくつかのドキュメントとともに、 Terminationトレイトをlibcore/ops/termination.rsに追加する必要があります。 また、 #[unstable(feature = "termination_trait", issue = "0")]属性を使用して不安定としてマークする必要があります。これにより、安定する前にユーザーが使用できなくなります。

次に、 src/librustc/middle/lang_items.rsでそれをlang-itemとしてマークする必要があります。 これは、コンパイラがmainの型チェック時にそれを検出できることを意味します（たとえば、0c3ac648f85cca1e8dd89dfff727a422bc1897a6を参照）。
つまり、次のことを意味します。

1. lang-itemsリストに追加します（ librustc/middle/lang_items.rs内）
2. #[cfg_attr(not(stage0), lang = "termination")]をTermination特性に追加します。 #[lang = "termination"]属性を追加できない理由は、「stage0」コンパイラ（ブートストラップ中）がterminationが存在することを認識しないため、追加できないためです。 libstdをコンパイルします。 stage0コンパイラを更新するときに、 cfg_attrを手動で削除します。
   詳細については、XXXのブートストラップドキュメントを参照してください。

メインでTerminationの使用を許可する

これは私が対処する方法を知っている興味深い部分です。 これは、タイプチェックではなく() mainを作成し（現在、 main function has wrong typeエラーが発生します）、機能することを意味します。

タイプチェックを行うには、最初に次の既存のエラーを削除する必要があります。
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_typeck/lib.rs#L171 -L218

次に、returnタイプがTerminationトレイトを実装していることを確認するチェックを追加する必要があります（ register_predicate_obligationを使用してトレイト義務を追加します-その使用法を検索します）。 それはここで行うことができます：
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_typeck/check/mod.rs#L1100 -L1108

他の部分はそれを機能させることです。 それはかなり簡単なはずです。 RFCが言うように、リターンタイプに対してlang_startをジェネリックにしたい。

lang_startは現在ここで定義されています：
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/libstd/rt.rs#L32

したがって、一般的でRFCに一致するように変更する必要があります。

#[lang = "start"]
fn lang_start<T: Termination>
    (main: fn() -> T, argc: isize, argv: *const *const u8) -> !
{
    use panic;
    use sys;
    use sys_common;
    use sys_common::thread_info;
    use thread::Thread;

    sys::init();

    sys::process::exit(unsafe {
        let main_guard = sys::thread::guard::init();
        sys::stack_overflow::init();

        // Next, set up the current Thread with the guard information we just
        // created. Note that this isn't necessary in general for new threads,
        // but we just do this to name the main thread and to give it correct
        // info about the stack bounds.
        let thread = Thread::new(Some("main".to_owned()));
        thread_info::set(main_guard, thread);

        // Store our args if necessary in a squirreled away location
        sys::args::init(argc, argv);

        // Let's run some code!
        let exitcode = panic::catch_unwind(|| main().report())
            .unwrap_or(101);

        sys_common::cleanup();
        exitcode
    });
}

そして、 create_entry_fnから呼び出す必要があります。 現在、 Instance::monoを使用して単相lang_startをインスタンス化しており、適切なsubstでmonomorphize::resolveを使用するように変更する必要があります。

https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_trans/base.rs#L697

doctestsでTerminationの使用を許可する

doctestがどのように機能するのかよくわかりません。 たぶん@alexcrichtonに聞いてください（それが私がすることです）？

#[test]でTerminationの使用を許可する

libtestがどのように機能するのかよくわかりません。 たぶん@alexcrichtonに聞いてください（それが私がすることです）？ 単体テストは基本的にマクロによって生成されるため、 ()以外の戻り型を処理するには、そのマクロまたはその呼び出し元を変更する必要があります。

@bkchr

少なくともIRC/gitterに参加できますか？

@bkchrがチェックインしている-私はあなたと@arielb1がしばらく前にgitterについて会話しているのを見ました、何か進歩はありますか？ どこかでしゃぶる？

申し訳ありませんが、これまでの進捗はありません。 現在、やることはたくさんありますが、今週中にこれを始める時間を見つけられることを願っています。

@bkchr助けが必要な場合は、私に知らせてください！

私は現在少し立ち往生しています、私は義務を作成したいと思います。 義務を作成するには、TraifRefが必要です。TraitRefの場合は、DefIdが必要です。 終了特性からDefIdを作成する方法に関するコードを誰かに教えてもらえますか？

@bkchrトレイトをlangアイテムリストに追加する必要があります。例： https ：//github.com/rust-lang/rust/blob/ade0b01ebf18550e41d24c6e36f91afaccd7f389/src/librustc/middle/lang_items.rs#L312
#[termination_trait]でマークされます。例： https ：//github.com/rust-lang/rust/blob/ade0b01ebf18550e41d24c6e36f91afaccd7f389/src/libcore/fmt/mod.rs#L525 -L526

ええ、それは問題ではありません、私はすでにそれをしました。 check_fn関数で終了特性をチェックする必要があります。 register_predicate_obligationを使用したいので、そのために終了特性のdefidが必要です。

ああ、必要なのはtcx.require_lang_item(TerminationTraitLangItem)だけです。

@bkchrどうですか？ もう一度チェックインするだけです。 =）忙しい場合でも心配はいりません。必要なすべての支援を受けていることを確認したいだけです。

申し訳ありませんが、現在忙しいです：/今まで、私は必要なすべての助けを得ました:)

これは、TerminationTraitをチェックするためのコードです： https ：//github.com/bkchr/rust/blob/f185e355d8970c3350269ddbc6dfe3b8f678dc44/src/librustc_typeck/check/mod.rs#L1108

関数の戻り型をチェックしていないと思いますか？ 次のエラーが発生します。

error[E0277]: the trait bound `Self: std::ops::Termination` is not satisfied
  --> src/rustc/rustc.rs:15:11
   |
15 | fn main() { rustc_driver::main() }
   |           ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::ops::Termination` is not implemented for `Self`
   |
   = help: consider adding a `where Self: std::ops::Termination` bound

関数の戻り型を確認するには、何を変更する必要がありますか？

@bkchr https://gitter.im/rust-impl-period/WG-compiler-middleでcompiler-middleワーキンググループgitterに参加し、httpsで＃rust-internalsIRCチャネルを試すことをお勧めします。 ：//chat.mibbit.com/？server = irc.mozilla.org％3A％2B6697＆channel =％23rust-internals。 :)

@bstrieええ、ありがとう、私はすでにギッターチャットの一部であり、私の問題を解決することができます。 :)

@bkchrあなたの問題はこの行にあります。 そこに構築したい特性参照は、 R: Terminationのようなものです。ここで、 Rは関数の戻り型です。 これは、トレイトのタイプパラメータ（この場合はSelf ）の代わりとなる値のセットである適切な「substs」を構築することによって指定されます。

ただし、トレイトでSubsts::identity_for_itemメソッドを呼び出しています。 これにより、トレイト定義自体の中で使用する置換が返されます。 つまり、この場合、 Terminationトレイトで宣言されたSelfパラメータをSelfにマッピングしています。 これは、 Terminatorトレイト内の関数の定義を確認する場合に適切ですが、ここではそれほど多くはありません。

代わりに必要なのは、エントリ関数の戻り型を取得することです。 これは、変数ret_tyまたはactual_ret_tyの1つにすぎません。 どちらでも構いませんが、 ret_tyの方が良いと思います。これは、ユーザーが宣言した戻り型に対応します（ actual_ret_tyは実際に返されるコードの型です）。

tcxからmk_substs()メソッドを呼び出すだけで、必要なsubstを作成できます。 この場合、パラメータはタイプだけなので、 let substs = fcx.tcx.mk_substs(&[ret_ty]);のようなものが機能すると思います。

使用するのはtcx.mk_substs_trait(ret_ty, &[])だと思います。

@bkchrはチェックインするだけです-そのアドバイスを使用する機会がありましたか？ （また、より速い応答のために、gitterで尋ねることは賢明かもしれません。）

ええ、私はgitterの問題を解決することができました:)

@bkchrどうですか？ チェックインするだけです。

すべて大丈夫です。おそらく今週はコードを調べる時間があります。

もう一人がこれを手伝う余地はありますか？ 年末までにRustコミュニティへの貢献を開始したいと思います。また、この機能を支援したいと思います。 うまくいけば、これについて2人が協力することはそれほど混乱しないでしょう。

@ U007D

これは小さな機能であり、 @bkchrはほとんどそれで完了しています。

ああ、わかりました-それは知っておくと良いことです、ありがとう。 私は私が助けることができる何か他のものに目を光らせていきます。

@ U007D https://www.rustaceans.org/findworkを見たことがありますか？

@lnicolaはい、あります！ 私は自分が取り組むことができると自信を持っている（つまり、ネットポジティブになる）何かの交差点で何かを見つけようとしていて、情熱を持っています。 正直なところ、私はRustを約1年間学んでいますが、何かのためにボランティアをするためにステップアップするのはまだ少し怖いです。 FWIW、それは決してRustコミュニティのせいではありません-Rustコミュニティはこれをオープンで歓迎的で包括的な文化にするために後ろ向きに曲がっています-私が経験した中で最高のものです。 （私は、チームが協調的ではなく競争的である傾向があるテクノロジー業界での長年の経験からの古い戦いの傷跡ともっと関係があると思います。）

とにかく、今年は何かを選び、少なくとも前向きな貢献を始めることが私の目標です。 私が参加する時が来ました！ :)

提案をありがとう、@lnicola。 それは良いリソースです。

@bkchr更新はありますか？

私はそれに取り組んでいます（https://github.com/rust-lang/rust/pull/46479）。 今、私は休日とプルリクエストのコメントで作業する時間があります。 すべての遅延について申し訳ありません：/

ああ、すみません、プルリクエストがあることに気づきませんでした。 それを架橋しました。

こんにちは、うーん。 ですから、私は、伝統と同様に、Rustの貢献者としてのキャリアをバイクシェッドから始めると思いました。 具体的には、これについて：

• []導入されている形質の名前

Exitどうですか？ それは短くて要点であり、既存のRustの語彙に適合します。 Exit-as-a-nounは、exit-as-a-verbの自然な対応物であり、ほとんどの場合、制御された方法で「内部から」プロセスを終了するためのよく知られた単語です。

特にC++プログラマーにとって、「終了」はstd::terminateを思い起こさせます。これは、デフォルトで異常終了（ abortを呼び出す）になり、基本的にC ++はパニックに相当します（ただし、パニックとは異なり、決して巻き戻されません。スタック）。

待って、そのコメントを無視してください。RFCが明示的に議論を開いたままになっているように見えます。

特性名としてExitが好きです。

Carrierで起こったように、この機能は特性が安定するずっと前に安定するだろうと私は考えています。

FWIWこれは、安定化の前に仮の名前が変更されたことを本当に嬉しく思うもう1つのケースです：D

RFCの作成者として、私はトレイトの名前をExit 、または他の何かに変更することに異論はありません。 私は物事に名前を付けるのが特に得意ではなく、他の誰かがより良いアイデアを持ってくれることを嬉しく思います。

https://github.com/rust-lang/rust/blob/5f7aeaf6e2b90e247a2d194d7bc0b642b287fc16/src/libstd/lib.rs#L507

特性はあるはずです

1. libcoreの代わりにlibstdに配置され、
2. $ std::ops::Termination std::Terminationと呼ばれますか？

Resultの実装では$＃ stderr $に出力する必要があり、 libcoreでは実行できないため、トレイトをlibcoreに配置できませんでした。

@bkchr implがlibstdにあるからといって、トレイトがlibstdにもある必要があるという意味ではありません。

@kennytm知っていますが、Resultはlibcoreでも定義されているため、libstdのResultにターミネーションを実装することはできません。

@zackw特性名として、 Exitにさらに+1票を投じます。

@ U007D ：そのようなメッセージを投稿する代わりに、リアクションボタン（例：👍）を使用していただけませんか？ これにより、不必要にpingを実行することで、問題のあるサブスクライバーを煩わしく回避できます。

language_feature libtest / libsyntaxをチェックインできますか？ @ arielb1 @nikomatsakis @alexcrichton

libsyntaxの@bkchrはそれを渡す必要があるかもしれませんが、理論的には可能ですが、実行時のlibtest自体では、チェックできるとは思いません。

@bkchrどうやってここに行くの？

私はまだそれに取り組んでいますが、現在私はこれ以上質問がありません:)

この実装は厳密すぎると思います。

#[unstable(feature = "termination_trait", issue = "43301")]
impl<T: Termination, E: Error> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(err) => {
                print_error(err);
                exit::FAILURE
            }
        }
    }
}


#[unstable(feature = "termination_trait", issue = "43301")]
fn print_error<E: Error>(err: E) {
    eprintln!("Error: {}", err.description());

    if let Some(ref err) = err.cause() {
        eprintln!("Caused by: {}", err.description());
    }
}

Errorを実装しない、一般的に使用されるエラーがいくつかあります。最も重要なのは、 Box<::std::error::Error>とfailure::Errorです。 また、このエラーの表示implの代わりにdescriptionメソッドを使用するのは間違いだと思います。

このimplをこのより広いimplに置き換えることを提案します：

#[unstable(feature = "termination_trait", issue = "43301")]
impl<T: Termination, E: Display> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(err) => {
                eprintln!("Error: {}", err)
                exit::FAILURE
            }
        }
    }
}

それは残念な原因チェーンを失います。

ただし、説明ではなくdisplayimplを使用する方が確実に優れています。

原因連鎖は興味深い問題です。 特に、この実装は、原因チェーンの最初の2つのメンバーのみを出力します。

失敗は、原因チェーンを処理する方法に対処する必要があり、デフォルトでこの動作に落ち着きました（たとえば、 .contextを使用してエラーを蓄積した場合：

• {}はこのエラーのみを出力します
• {:?}は、このエラーとその原因を（再帰的に）出力します

ここで:?を使用して、DisplayではなくDebugにバインドすることもできます。 わからない。

ええ、私はサポートするためにimplを改善する必要があることをすでに知っています。 私は私たちに何ができるかについてオープンです。 Debugにバインドするのは良い考えかもしれません。

うーん、これはトリッキーなものです。 「洗練された」プログラムがこの特性の暗黙を利用すると私たちが考えるかどうかに依存すると思います。 「いいえ、そうではありません」と言っても大丈夫だと思う傾向があります。基本的に、洗練されたプログラムは、（a）出力をキャッチして他の方法で処理するか、（b）新しいタイプまたはデバッグを実装するものを使用します。正しい方法。 これは、有用な情報をダンプするためにimplを最適化できることを意味しますが、必然的に最も美しい形式（ Debugの役割のようです）になります。

Debugを使用して、これを非常に明確にプロトタイピングの対象にすることは正しい選択かもしれません。ほとんどの本番ユースケースに適した方法でエラーを自動的に処理できるとは思わないからです。

@withoutboats同意します。

@nikomatsakisあなたは「必ずしも最も美しい形である必要はない」という意味だと思いますか？ もしそうなら、はい、私は同意します。

更新：これに数日間取り組んだ後、私はこれを裏返しました。 下記参照。

：+1： Debugで、ここ; https://github.com/rust-lang/rfcs/pull/1937#issuecomment-284509933からの@nikomatsakisの「キャッチされない例外に類似した種類」が好きです。 Debugを示唆するDiggseyからのコメント： https ：//github.com/rust-lang/rfcs/pull/1937#issuecomment -289248751

参考までに、「より完全な」vs「よりユーザーフレンドリーな」デフォルト（つまりDebugとDisplayの特性制限）の問題を切り替えました。

TL; DRは、「何もしない」場合に、よりクリーンで要約出力を提供するために、境界をDisplayに設定する必要があると考えています（ @withoutboatsの元の投稿による）。

これが私の理論的根拠です：

terminationトレイトのRFCの問題で、 @ zackwは、 Rustがデュアルpanic / Resultシステムを持っているという説得力のあるポイントを示しています。これは、 panicがバグとResult用であるためです。

もちろん、誰もが満足できるデフォルトは1つではないので、驚き最小の原則を適用して、どちらのデフォルトがより適切かを自問します。

• エラーは、何か（おそらく修正可能）が間違っている（ファイルが見つからないなど）ことをユーザーに伝えることを目的としているため、設計では処理されないことがよくあります。 そのため、ユースケースが存在し、ユーザーが対象読者であることが一般的であると合理的に見なすことができます。

• @nikomatsakisが指摘したように、選択したデフォルトに関係なく、動作を変更したい開発者は、newtypeパターンを使用するか、main（）でカスタム実装を開発できます。

そして最後に、より主観的な側面として、過去2日間にこの機能を使用したところ、 Debugの出力により、「Rustアプリ」がより洗練されていないように感じられました。

$ foo
Error: Custom { kind: Other, error: StringError("returned Box<Error> from main()") }
$

vs

$ foo
Error: returned Box<Error> from main()
$

Dispay特性は、（バグではなく）エラーのはるかに文明的なデフォルトのようですが、そうではありませんか？

@ U007D待ってください、これら2つの出力のどちらが好きですか？

（a） Error: Custom { kind: Other, error: StringError("returned Box<Error> from main()") }

また

（b） Error: returned Box<Error> from main()

彼はオプション（b）を好みます。

@nikomatsakis元々、私はa） Debugを頭の中でコンセプトとして使用して問題ありませんでしたが、実際に出力を確認して数日間使用した後、 b） Displayを使用するようになりました。デフォルト。 連鎖エラーをモデル化した場合、b）に対する私の好みはさらに顕著になると思います。

「洗練された」または「文明化された」がこれの目標ではないと思いますが、スレッドがこれをほとんど例としてすでに受け入れていることを理解していたので、プログラムが成熟するにつれてカスタム処理を追加することが人々に完全に期待されています。

そのような場合、私にとって「驚き最小の原則」は、 unwrapのような開発者向けの出力です。

長いエラーが懸念される場合は、ここで{:#?}について説明する価値がありますか？

エンドユーザー向けのエラー報告は、ツールやユースケースごとに異なりますが、開発者向けのエラー報告は、Rustが.unwrap()などの他の状況で行うものと似ている必要があります。 デフォルトは1つしか存在できず、洗練されたソフトウェアはとにかく出力をオーバーライドする必要があるため、 Debugを使用して開発者向けのデフォルトに投票します。

この議論の核心は、本当に「デフォルトのメッセージのターゲットオーディエンスは誰か」だと思います。

少しの間、デフォルトのターゲットオーディエンスが開発者であることに全員が同意したとしましょう。 Debugのデフォルトの範囲は簡単な選択だと思います。

ここで、デフォルトのターゲットオーディエンスがユーザーであることに同意したとしましょう。ここで、それぞれ、他の人とは意見が一致せず、「洗練された」出力や「文明化された」出力などの主観的な品質が重要な役割を果たしていると感じます。遊ぶ。 一部の人にとっては、エンドユーザーによるプレゼンテーションの「磨き」がDisplayを回避するための最良の理由かもしれません。 （私はたまたまその見解を共有していませんが、私はそれを理解し、尊重しています。）

そうです、私は確かにどちらかのグループの妥当な議論をデフォルトのターゲットとして見ることができます。 どのオーディエンスをデフォルトのターゲットにするかについて強いコンセンサスが得られれば、特性の限界の選択は明確になると思います（er）... :)

（私はこのトピック全体に完全に精通していませんが） Terminationのデフォルトのエラー出力がユーザーに表示可能な形式である場合、それが完全に適切である小さなユーティリティが存在する可能性は考えられません。 Displayのように？ その場合、作者が「カスタム処理」のために手を差し伸べなければならない唯一の理由は、私たちがそれらを作成するかどうかです。

誰かがそれぞれの場合の出力がどのように見えるかの例を提供できますか（使用される特定のEタイプにも依存すると思いますか？）、「カスタム処理」が必要な場合に作成者が実際に実行する必要のある手順は何ですか？代わりは？ 私は上記の仮説を立てています。

（出力は文字通り@ U007Dが上に貼り付けたもののように見えますか？なぜ「returnedBox\」と出力されるのでしょうか。Box <エラー>？）

エラーメッセージのDisplayでさえ、どれくらいの頻度でユーザーフレンドリーですか？ たとえば、次のプログラム：

fn main() {
    if let Err(e) = std::fs::File::open("foo") {
        println!("{}", e)
    }
}

次のメッセージを出力します。

No such file or directory (os error 2)

これは、特にファイル名が言及されていない場合、優れたUXではないと思います。 少なくとも、プログラムが文字通り単一のファイル名を入力として受け取らない限り、そうではありません。 一方、ソースファイル/行番号/スタックトレースが欠落しているため、開発者の経験もあまり良くありません。 Debugの出力は、明らかにユーザーエクスペリエンスがさらに悪く、デセロパーにとっても有用な情報を追加しません。

ですから、私が言おうとしているのは、ライブラリエラー自体の情報コンテンツを改善しなければ、 DebugもDisplayも素晴らしいものではないということだと思います。

出力は文字通り@U007Dが上に貼り付けたもののように見えますか？ なぜ「返品されたボックス」を印刷するのでしょうかそのボックスの実際の内容の代わりにmain（）"から？

@glaebhoerl正解です。この場合、「そのBox<Error>の実際の内容」は、 termination_traitをテストするために作成したカスタムのmessageフィールドであり、逐語的に表示されます。 。 代わりに「foobarbaz」などを書くこともできます（ただし、コンパイラテストを実行するユーザーにとってはそれほど役に立たなかった可能性があります）。

@jdahlstromの例を使用して、 Box ed標準ライブラリ"file not found" Errorの実際の出力を次に示します（正しく指摘しているように、ボクシングについてはどこにも言及されていません）。
Debug ：

$ foo
Error { repr: Os { code: 2, message: "No such file or directory" } }
$

およびDisplay ：

$ foo
No such file or directory (os error 2)
$

@jdahlstrom私はあなたが良い点を作っていると思います。 私は、両方のメッセージがターゲットオーディエンスに十分に役立たない可能性がある一方で、間違ったメッセージを提供することはさらに悪いことを強調したいと思います（あなたがほのめかしたと思います）：

開発者にDisplayを提供すると、 Debugのすべての欠点に加えて、表示されているエラータイプの特異性が失われます。

ユーザーにDebugを提供すると、 Displayのすべての欠点に加えて、ユーザーが必要とせず、理解できない可能性のある技術情報がさらに追加されます。

そうです、私はメッセージがどちらの聴衆にも十分にターゲティングされていないことが多いことに同意します。 これは、私たちが誰をターゲットにしているのかを明確にするもう1つの重要な理由を浮き彫りにし、そのグループに可能な限り最高のエクスペリエンスを提供できると思います。

#[test]に?のサポートを実装するには、いくつかの助けが必要です。 私の現在の実装はここにあります： https ：//github.com/rust-lang/rust/compare/master ... bkchr：termination_trait_in_tests

変更を加えてテストをコンパイルすると、次のエラーが発生します。

error: use of unstable library feature 'test' (see issue #27812)
  |
  = help: add #![feature(test)] to the crate attributes to enable

@eddybは、 quote_item!/expr!はレガシーであるため、もう使用しないでくださいと言いました。
今、私は何をすべきですか、新しいquote!マクロに切り替えるか、すべてを手動のast構築に作り直しますか？

私はどんな助けにも感謝します:)

libtestで定義されたマクロへのマクロ呼び出しを生成することは非常にうまくいくと思います。

@eddybここであなたの提案を理解できるかどうかわかりません：

libtestで定義されたマクロへのマクロ呼び出しを生成することは非常にうまくいくと思います。

ああ、多分そうだと思います。 あなたが言っているのは、libtestでマクロを定義してから、それを呼び出すコードを生成するということですか？ 面白いアイデア。 しかし、そのマクロ名は一種の「リーク」ではないでしょうか。 （つまり、libtestのパブリックインターフェイスの一部になりますか？）

@bkchr

変更を加えてテストをコンパイルすると、次のエラーが発生します。

なぜそのエラーが発生するのか分かりますか？ 差分を読んだだけではわかりませんが、ローカルでビルドして理解することはできます。

quote_item!/expr!はレガシーなので、もう使用しないでください。

ここでは強い意見はありません。 @eddybはレガシーであることに同意しますが、いくつかの用途を追加すると削除が難しくなるようなレガシーであるかどうかはわかりません。つまり、最近の交換を取得すると、簡単になります。 @eddybは、一方から他方に移動しますか？

手動のAST構築は確かに苦痛ですが、そのためのヘルパーがいると思います。

ほとんどの場合、小さな編集を行う必要がありますよね？ つまり、関数の呼び出しからreport()の結果のテストに変更しますか？

PS、スコープ内にあるTermination特性に依存することを避けるために、 .report()表記を使用するのではなく、 Termination::report(...)のようなものを生成したいと思うでしょうか。

いいえ、そのエラーがどこから来ているのかわかりません:(

RFCは、元のテスト関数を呼び出すラッパー関数を生成することを提案しました。 それは私の現在のやり方でもあります。
ラッパー関数を削除することもできると思いますが、各テスト関数は異なる型を返す可能性があるため、関数ポインターをボックス化する必要があります。

うーん、テストはすでに他のものをインポートしているので、終了特性もインポートするのはそれほど複雑ではありません。

@alexcrichtonこのエラーがどこから来ているのか、あなたはおそらく知っていますか？

@nikomatsakis libtestは不安定であり、そうでない場合でもマクロを不安定としてマークすることはできませんか？

@eddybああ、良い点。

RFCは、元のテスト関数を呼び出すラッパー関数を生成することを提案しました。 それは私の現在のやり方でもあります。

ラッパー関数は私には問題ないようです。

@eddybとマクロは、 libtestで定義されているcreate_testのようなものを意味しますか？ しかし、私が理解していないのは、「マクロを不安定としてマークする」ことです。 それで何をするつもりですか？ 例を挙げていただけますか？

@bkchrマクロ定義に#[unstable(...)]属性を設定します。例： https ：//github.com/rust-lang/rust/blob/3a39b2aa5a68dd07aacab2106db3927f666a485a/src/libstd/thread/local.rs#L159 -L165

したがって、この最初のチェックボックスは...

RFCを実装する

...リンクされたPRがマージされたことを確認しますか？

@ErichDonGubler完了:)

うーん、現在、マージされたprで実装されているのは半分のrfcだけです^^

3つのチェックボックスに分かれています:)

私はこの機能をmainで使用しようとしてきましたが、かなりイライラすることがわかりました。 終了特性の既存の実装では、複数の種類のエラーを便利に「蓄積」することができません。たとえば、 Errorを実装していないため、 failure::Failを使用できません。 Error ; 同じ理由でBox<Error>を使用できません。 Debugへの変更を優先する必要があると思います。 =）

こんにちは、 @ nikomatsakis 、

termination_traitを使おうとしたときとまったく同じ欲求不満を感じました。

それは、コンパイラのハッキングに関するあなたの投稿と相まって、今月初めにこの問題に取り組むように私を刺激しました。 https://github.com/rust-lang/rust/pull/47544で、テストとともにDisplay （および前のコミットではDebug ）のimplを投稿しました。 （それは非常にマイナーですが、それでも、私の最初のRustコンパイラPR！：tada :) :)

私の理解では、langチームはどの特性を使用するかについて電話をかけますが、いずれにしても、実装は準備ができています。

私がまだ興味を持っている質問：デフォルトのエラーメッセージ出力（ DebugまたはDisplay ）に依存せず、代わりに独自の出力が必要だとしたら、どうしますか？それ？ （これがすでにどこかに書き留められていて、私がそれを見逃した場合はお詫びします。） ? -in- mainの使用を完全にやめる必要はありませんか？ それはあなた自身の結果および/またはエラータイプおよび/またはimplを書くようなものですか？ （ ? -in- mainが単なるおもちゃであり、「真剣になりたい」と思ったらすぐに人間工学に基づいた方法に戻らなければならないのは残念なことです。）

@glaebhoerlそれは非常に簡単です：

1. 新しいタイプを作成します。
2. 古いエラータイプのFromを実装します。
3. Debug （またはDisplay ）を実装します。
4. mainの署名のタイプを置き換えます。

ありがとう！

デバッグ指向ではないDebugのカスタム実装を作成するのは少し奇妙に思えますが、それは世界の終わりではないと思います。

@glaebhoerlそのため、 Result implはDebug IMOではなくDisplayを使用する必要があります。

Terminationトレイトに、 message 、またはerror_messageなどの追加のメソッドを含めることはできません。このメソッドには、 Debug /を使用するデフォルトの実装があります。メッセージを表示するにはDisplay ？ 次に、新しいタイプを作成するのではなく、単一のメソッドを実装する必要があります。

@glaebhoerl @Thomasdezeeuw error_messageメソッドのようなものがRFCの元のドラフトにありましたが、コンセンサスの欠如のために削除されました。 当時の私の気持ちは、基本的な機能を着陸させて（必ずしも安定させる必要はない）、それから繰り返すのが最善だと思っていました。

@zackw同意しました。個人的には、メッセージはなく、数字だけで大丈夫です。エラーコードについては0と1としましょう。 しかし、最初の反復でメッセージングを取得したい場合は、 DebugまたはDisplayの何よりもTermination::messageを支持すると思います。

そのmessageメソッドはStringを返しますか？ それはTerminationがlibcoreにあることと互換性がないのではないでしょうか？

@SimonSapin Terminationは現在libstdで定義されています。

うーん、でも、トレイトにメソッドmessageを追加するのが最善の実装だとは思いません。 i32のようなタイプの場合、メソッドは何を返しますか？ このメッセージをいつ印刷するかをどのように決定しますか？ 現在、 ResultにTerminationを実装すると、 report関数にエラーが出力されます。 Resultは、それがErrであることを知っているので、これは機能します。 チェックreport() != 0をどこかに統合してから印刷することもできますが、それは正しくありません。
次の問題は、 Resultの標準実装を提供したいということですが、 Errorタイプは、おそらく印刷するために何を実装する必要がありますか？ これにより、現在の質問DebugまたはDisplayに戻ります。

「深刻な」プログラムでメインで?を使用したい場合に発生する別の頭痛の種は、状況によっては、コマンドラインプログラムがゼロ以外のステータスで終了したいが_anything_を出力しないことです（ grep -qを検討してください）。 ErrorではないものにTermination implが必要になります。これは何も出力せず、終了ステータスを制御できます...そして、あなたがコマンドライン引数を解析した後、そのことを返します。

これは私が思うことです：

Result<T, E>を返す場合は、Eのdebug implを使用する必要があります。これは最も便利な特性です。広く実装されており、「クイックアンドダーティ出力」のユースケースと単体テストのユースケースを満たしています。 Displayはあまり広く実装されていないことと、これが洗練された出力であるという印象を与えることの両方から、使用したくないと思います。

しかし、プロ並みの出力を得る方法もあるはずです。 幸いなことに、そのような方法はすでに2つあります。 まず、 @ withoutboatsが言ったように、 E: Displayを使用したい場合、またはプロのスタイルの出力を提供したい場合は、「デバッグからの表示」ブリッジを作成できます。 しかし、これがあまりにもハッキーだと感じた場合は、結果を置き換えるために独自のタイプを定義することもできます。 たとえば、次のようにします。

fn main() -> ProfessionalLookingResult {
    ...
}

次に、 ProfessionalLookingResult Tryを実装します。 次に、 Terminateも実装できます。

impl Terminate for ProfessionalLookingResult {
    fn report(self) -> i32 {
        ...
        eprintln!("Something very professional here.");
        return 1;
        ...
    }
}

これはDebugを使用する必要があるという@nikomatsakisに同意します。

また、洗練された出力の場合、 TryとTerminateを実装する新しい型を作成するよりも、 mainでコードを書く方がおそらく良いと思います。 Terminateのポイントは、ライブラリが簡単に適切なデフォルトを作成できることであるように思われます。これは、プログラムの終了方法がエンドユーザー（プロのCLIなど）にとって重要である状況では決して当てはまりません。 。

もちろん、他の人は異なる意見を持っているかもしれません。 mainに直接書き込む代わりに、関連する特性を使用してコードを挿入する方法は複数あります。 素晴らしいのは、複数の選択肢があり、エラーを常に処理するための1つの祝福された方法を考え出す必要がないことです。

いくつかの問題がありますが、いくつかの考えを書き留めておきます。

私は以下を見たいです

fn main() -> i32 {
    1
}

これは、より一般的に次のように書くことができます。

fn main() -> impl Display {
    1
}

これらのメイン関数は両方とも、0の終了コードとprintln!の1のDisplayを返す必要があります。

これは次のように単純なはずです（私は思います）。

impl<T> Termination for T where T: Display {
    fn report(self) -> i32 {
        println!("{}", self);
        EXIT_SUCCESS
    }
}

次に、エラーの場合は次のようになります。

impl<T: Termination, E: Debug> Termination for Result<T, E> { ... }

ここで、実装はRFCと同じですが、使用するの"{:?}"だけです。
Debug形式。

前に述べたように、出力をより細かく制御する必要がある人は、単純に
書きます：

fn main() -> Result<i32, MyError> { ... }
impl Termination for Result<i32, MyError> { ... }

これは現在のコンパイラでは決定不可能ですが、
競合する実装が表示されます...したがって、 @nikomatsakisが提案することを実行します
そして書く：

fn main() -> MyResult { ... }
impl Termination for MyResult { ... }
or, if you want something more general.
impl<T, E> Termination for MyResult<T, E> { ... }

これは部分的に言われていることを言い換えていることを私は知っていますが、私は自分のビジョンを完全に提示し、結果だけでなく戻り値を表示するためのより一般的な解決策を示したいと思いました。 このコメントの多くは、デフォルトで出荷されるTerminationの実装について議論しているようです。 また、このコメントは、RFCで説明されているimpl Termination for boolのような実装と矛盾しています。 個人的には、ゼロ以外の終了コードは、 ResultsまたはTerminationを実装するカスタムタイプによって排他的に処理する必要があると思います。

Displayの実装がないため、メインのOptionタイプで?を処理する方法については興味深い質問です。

TL; DR： Debugで大丈夫です。

より詳細な説明：
私はこれについて昨日と今日について考えることに時間を費やし、可能な限り最良の答えに到達するのを助けるために私が持っている、または作っている暗黙の仮定を明らかにすることを目的としました。

重要な前提条件：Rustで記述できるさまざまな種類のアプリケーションの中で、コンソールアプリは、この決定によって最も恩恵を受ける/最も影響を受けると思います。 私の考えでは、ライブラリ、AAAゲームのタイトル、IDE、または独自の制御システムを作成する場合、デフォルトのメインターミネーション特性が箱から出して必要なものを満たすことはおそらく期待できません（実際、主要）。 したがって、デフォルトとしてDisplayに偏るのは、小さなコマンドラインアプリケーションを使用したときに予想されるものから来ています。たとえば、次のようになります。

$ cd foo
bash: cd: foo: No such file or directory

私たちのほとんどは、どんな種類のデバッグ支援も期待していません。何がうまくいかなかったかを示す簡潔な指標にすぎません。 私は単にこれをデフォルトの位置として提唱しています。

このような単純な出力を得るためにTerminate implを書くことを考えると、主な機能からの?は、今日の安定した錆とそれほど変わらないことに気付きます（書かれたコードの量に関して） ）、ここで、 Eを処理するためにResult対応の「inner_main（）」が作成されることがよくあります。

この仮定を念頭に置いて、思考演習として、今日存在する「 inner_main() 」スタイルの実装の優位性がよりカジュアルなDisplayフレーバーであると強く感じたかどうかを判断しようとしました。 （より技術的なDebugフレーバー以上）。 私の考えでは、これはその機能が実際にどのように使用される可能性が高いかを示していると思いました。

私はこれが事実であると自分自身を納得させることができませんでした。 （つまり、現在、既存の実装ではDisplayに対する強いバイアスは存在しないと思います）。 実際、過去16か月間に作成した自分のリポジトリを調べたところ、両方のケースが十分にあることがわかりました。デフォルトDisplayを実装すると、正味の節約になるとは言えません。

「主な受益者はCLIアプリケーションである」という前提を維持し、ヘルプと使用法の情報を提供するコンソールアプリは多数あります。 例えば：

$ git foo
git: 'foo' is not a git command. See 'git --help'.

The most similar command is
    log

そのため、コンソールアプリの場合でも、 Debugを使用して「負傷したグループ」を特定するのは困難です。

そして最後に、 Debug implの方が、この機能をさらに6か月間保持するよりも幸せになるので、勝手にそれがあります:)。

ですから、私の思考プロセスは公の場で提示されています。 要約すると、 DebugはDisplayより良くも悪くもないと思います。したがって、デフォルトの実装としては問題ないはずです。

多くの皆さんと同じように、「はい、それだけです!!!」、TBHのように、私がもっとワクワクした実装があったらいいのにと思います。 しかし、それは非現実的であるという私の期待だけかもしれません...たぶん、私のプロジェクトでボイラープレートを削減するfailureで機能するソリューションがあれば、それは私に成長します。 :)

テストで終了特性をサポートするためにPRを開いたことに注意してください：＃48143（ @bkchrの作業に基づいて構築）。

テストの結果を処理するためのメソッドを使用して、 Terminationトレイトを自由に拡張しました。 これにより実装が簡素化されましたが、テストの失敗は実行可能な失敗よりも詳細な出力が必要になる可能性があるため、これも理にかなっています。

Terminationは、libstdの特性の動詞に対する一般的な設定に基づいて、 Terminateに名前を変更する必要があります。

@withoutboatsある時点で、動詞の特性は、その特性と同じ名前の単一のメソッドを持つものがほとんどであるという議論があったと思います。 とにかく、私は自分の自転車小屋の提案、 Exitをもう一度浮かぶことができますか？

無償のバイクシェディング：これは単一メソッドの特性です。 同じ名前を付けたい場合は、おそらくToExitCode / to_exit_code ？

Resultを返すことを安定させることは、特性を安定させることとは独立して行うことができますよね？

私にとって、これは?のように感じられ、ほとんどの値は言語機能から得られ、特性の理解を遅らせることができます。 RFCの議論では、コードをinner_mainに配置する方が、このためのトレイトimplよりも簡単に思えたので、トレイトを安定させる必要があるかどうかさえ疑問に思いました...

はい、特性を安定させる必要はありません。ただし、フレームワークのように、必ずしもinner_mainにあまり依存できない場合は、安定した状態で役立ちます。

@SimonSapin Toは型変換を指すと思いますが、そうではありません。 しかし、メソッドterminateという名前を付けることもできます（また、特性動詞に名前を付けるタイミングに関するこの制限は当てはまらないと思います。 Tryは明らかな反例です）。

Tが単位ではない場合にfn main() -> Tを安定させることを提案しました。 これにより、多くの詳細（特に特性の名前/場所/詳細）が不安定になりますが、いくつかは修正されています。 詳細はこちら：

https://github.com/rust-lang/rust/issues/48453

フィードバックをお寄せください。

terminateは、 reportよりもわかりやすいようです。 常にterminateですが、 reportを省略できます。

ただし、たとえばstd::process::exitとは異なり、このメソッドは何も終了しません。 main()の戻り値のみを終了コードに変換します（オプションResult::Errをstderrに出力した後）。

Exitへの別の投票。 簡潔で、非常に説明的で、終了コード/終了ステータスの従来の概念と一致していることが気に入っています。

何かが本当にうまくいかなかったために突然ハードに終了するのではなく、メインから戻って優雅に終了するので、 TerminateよりもExitの方が間違いなく好きです。

結果を返す安定化単体テストを提案するために、 https：//github.com/rust-lang/rust/issues/48854を追加しました。

ああ、私はこれについて話すのに適切な場所を見つけました。

doctestsで?を使用する

doctestsが現在機能する方法は、次のようなものです。

• rustdocは、doctestをスキャンして、 fn mainを宣言しているかどうかを確認します。
  
  
  
  • （現在、 //の後にない「fnmain」の行ごとのテキスト検索を実行します）
  
  
• fn mainが見つかった場合、それはすでにそこにあるものには触れません
• fn mainが見つからなかった場合は、ほとんどのdoctest*が基本的なfn main() { }にラップされます。
  
  
  
  • *フルバージョン： #![inner_attributes]およびextern crate宣言を抽出し、生成されたmain関数の外部に配置しますが、それ以外はすべて内部に配置されます。
  
  
• doctestにexterncrateステートメントが含まれていない場合（および文書化されているクレートがstdと呼ばれていない場合）、rustdocは生成されたmain関数の直前にextern crate my_crate;ステートメントも挿入します。
• 次に、rustdocは、テストハーネスの一部として、最終結果をコンパイルしてスタンドアロンバイナリとして実行します。

（私はいくつかの詳細を省略しましたが、私は便利にここで完全な記事を書きました。）

したがって、doctestで?シームレスに使用するには、変更する必要があるのはfn main() { your_code_here(); }を追加する部分です。独自のfn main() -> Result<(), Error>を宣言すると、できるだけ早く機能します。通常のコードでは、rustdocをそこで変更する必要はありません。 ただし、mainを手動で宣言せずに機能させるには、微調整が必​​要になります。 この機能に厳密に従っていないので、万能の解決策があるかどうかはわかりません。 fn main() -> impl Termination可能ですか？

fn main（）-> impl終了は可能ですか？

浅い意味では、はい： https ://play.rust-lang.org/?gist=8e353379f77a546d152c9113414a88f7&version=nightly

残念ながら、 -> impl Traitは、使用するタイプを指示するための推論コンテキストを必要とする組み込みのエラー変換のために、 ?で基本的に厄介だと思います： https：//play.rust- lang.org/?gist=23410fa4fa684710bc75e16f0714ec4b&version=nightly

個人的には、 ? -in-doctestsがhttps://github.com/rust-lang/rfcs/pull/2107のようなものを介してfn main() -> Result<(), Box<Debug>> catch { your_code_here(); }として機能することを想像していました（https：//の構文を使用） github.com/rust-lang/rust/issues/41414#issuecomment-373985777）。

impl Traitバージョンはかっこいいですが、rustcが? desugarで内部的に使用できる「制約のない場合は同じタイプを優先する」サポートがあれば機能する可能性がありますが、私の記憶はそのような機能のアイデアは、物事がどのように機能するかを理解している人々を恐怖で反動させる傾向があること：sweat_smile：しかし、出力がimpl Traitの場合にのみ適用される内部的なものである可能性があります...

ああ、それらは非常に現実的な懸念です。 それが型推論をどのように台無しにするかを忘れていました。 キャッチブロックがそのリンクされた問題のようにOk-wrappingを開始した場合、それははるかに簡単な（そしてはるかに速く、安定化の観点から）前進の道のように思えます。

私が疑問に思う唯一のことは、それがエディションの移行によってどのように影響を受けるかということです。 catch構文は2018年の時代に変更されていませんか？ Rustdocは、実行しているライブラリと同じエディションでdoctestをコンパイルする可能性が高いため、渡されたエポックフラグに基づいて構文を区別する必要があります。

これが安定しているのではないかと心配していますが、単純なケースはまだICEです： https ：//github.com/rust-lang/rust/issues/48890#issuecomment -375952342

fn main() -> Result<(), &'static str> {
    Err("An error message for you")
}

assertion failed: !substs.has_erasable_regions(), librustc_trans_utils/symbol_names.rs:169:9

https://play.rust-lang.org/?gist=fe6ae28c67e7d3195a3731839d4aac84&version=nightly

どの時点で「これはバグが多すぎて不安定にする必要がある」と言いますか？ これが現在の形で安定したチャネルにヒットした場合、多くの混乱を引き起こすようです。

@frewsxcv問題は今修正されたと思いますよね？

@nikomatsakis https://github.com/rust-lang/rust/issues/48389で提起した問題は、1.26-betaで解決されているので、私の観点からはそうです。

はい、心配していたICEが修正されました！

おそらく手遅れになってしまったことをお詫びしますが、万が一の場合に備えて、ここにフィードバックを残したいと思います。 私はこのスレッドのほとんどを読んだので、その文脈を念頭に置いて話します。 ただし、このスレッドは長いので、見落としているように見える場合は、見落としている可能性がありますので、ご指摘いただければ幸いです。 :-)

TL;DR-エラーのDebugメッセージを表示するのは間違いであり、エラーのDisplayメッセージを使用するのがより良い選択だと思います。

私の信念の核心は、_RustでCLIプログラムを日常的に構築する_人として、 ErrorのDebugメッセージが何であるかをあまり気にかけたことを思い出せないということです。 つまり、エラーのDebugは、設計上、開発者向けであり、エンドユーザー向けではありません。 CLIプログラムを作成する場合、そのインターフェイスは基本的にエンドユーザーが読むことを目的としているため、ここではDebugメッセージの有用性はほとんどありません。 つまり、エンドユーザーに出荷したCLIプログラムのいずれかが、通常の操作でRust値のデバッグ表現を示した場合、バグは修正されると考えられます。 これは、Rustで記述されたすべてのCLIプログラムに当てはまるはずですが、合理的な人々が反対する可能性がある点かもしれないと私は理解しています。 そうは言っても、私の意見のやや驚くべき意味は、デフォルトの動作モードで修正が必要なバグ（ここでもIMO）から始まる機能を効果的に安定させたことです。

デフォルトでエラーのDebug表現を表示することにより、私たちはまた、不適切な慣行を奨励していると思います。 特に、Rust CLIプログラムを作成する過程で、エラーのDisplay implでさえ、エンドユーザーが消費するには不十分であり、実際の作業を行う必要があることを確認することは非常に一般的です。修理する。 この具体的な例はio::Errorです。 対応するファイルパスなしでio::Errorを表示すること（ファイルの読み取り/書き込み/オープン/作成からのものであると想定）は、エンドユーザーがそれを使って何かを行うのが難しいため、基本的にバグです。 デフォルトでエラーのDebug表現を表示することを選択することにより、CLIプログラムを作成する人々がそのような種類のバグを発見するのを難しくしました。 （それに加えて、 io::ErrorのDebugは、そのDisplayよりもはるかに有用ではありませんが、それ自体は私の経験では大きな問題ではありません。 ）。

最後に、私の議論を締めくくるために、私は例でも?-in-mainを使用する状況を想像するのにも苦労しています。 つまり、私は実際のプログラムにできるだけ一致する例を書こうとしてきましたが、これには通常、次のようなものを書くことが含まれます。

use std::error::Error;
use std::process;

fn try_main() -> Result<(), Box<Error>> {
    // do stuff with `?`
}

fn main() {
    if let Err(err) = try_main() {
        eprintln!("{}", err);
        process::exit(1);
    }
}

一見すると、これを?-in-mainに置き換えるのは_素敵です_ですが、 Displayのエラーが表示されないため、できません。 つまり、実際のCLIプログラムを作成するときは、実際には上記のアプローチを使用するので、例に現実を反映させたい場合は、ショートカットを使用せずに、実際のプログラムで何をするかを示す必要があると思います（妥当な範囲で） ）。 私は実際、この種のことは本当に重要だと思います。これの歴史的な副作用の1つは、 unwrapどこにでも散らかさずに慣用的なRustコードを書く方法を人々に示したことです。 しかし、私の例で?-in-mainを使用するように戻すと、目標を再設定しました。現在、デフォルトで非常に出力するプログラムを作成するだけではよくわからない人を設定しています。役に立たないエラーメッセージ。

「エラーメッセージを送信し、適切なエラーコードで終了する」というパターンは、実際には洗練されたプログラムで使用されています。 たとえば、 ?-in-mainがDisplay $を使用した場合、今日ripgrepのmain ＃$関数とrun関数をマージできます。

https://github.com/BurntSushi/ripgrep/blob/64317bda9f497d66bbeffa71ae6328601167a5bd/src/main.rs#L56 -L86

もちろん、将来、 Terminationの特性が安定したら、独自のimplを提供することで、 ?-in-mainを使用できますが、 mainを書き出すことができれば、なぜそれをわざわざ行うのでしょうか。私が持っているimplを含める必要があります。その時点で、今日の例に固執することもできます（ mainとtry_main ）。

見た目からすると、これを修正することは重大な変更になると思われます。 つまり、このコードは今日のRust安定版でコンパイルされます。

#[derive(Debug)]
struct OnlyDebug;

fn main() -> Result<(), OnlyDebug> {
    Err(OnlyDebug)
}

Displayに切り替えると、このコードが壊れると思います。 でも、よくわかりません！ これが本当に船の帆の問題である場合、私は理解しており、要点を詳しく説明することにはあまり意味がありませんが、少なくとも何かを言って、他の人を説得して見ることができないかどうかを確認するのに十分強いと感じていますそれを修正するためにできることがあれば。 （私がここで過剰反応している可能性も十分にありますが、これまでのところ、CSVの例で「なぜ?-in-mainを使用しないのですか？」 「それがどのように実現可能かはわかりません。」おそらくそれは?-in-mainによって解決されることを意図した問題ではなかったかもしれませんが、一部の人々は確かにその印象を持っていました。現在の実装では、ドキュメントテストや単体テストで役立つことがわかりましたが、他の状況で使用することを考えるのは難しいです。）

Debug Displayを表示する方が、CLIアプリケーションに適していることに同意します。 Debug $ではなくDisplayにする必要があることに同意しません。これは、実際に?で実行できるエラーを大幅に制限し、 ?-in-mainの目的を損なうためです。 Displayを使用し、利用できない場合はDebugにフォールバックすることができます。

#[unstable(feature = "termination_trait_lib", issue = "43301")]
impl<E: fmt::Display> Termination for Result<!, E> {
    fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {}", err);
        ExitCode::FAILURE.report()
    }
}

最後に、私の議論を締めくくるために、私はまた、例においてさえ、私がメインで？-in-mainを使用する状況を想像するのに苦労しています。

実際のCLIプログラムについては一般的に@BurntSushiに同意する必要がありますが、私だけが使用する予定のランダムなスクリプトや内部ツールの場合、これは非常に便利です。 また、試作品やおもちゃにもとても便利です。 実際に本番コードで使用することを常に思いとどまらせることができますよね？

？-in-mainの目標の一部は、コード例での単一のコード、つまりアンラップを回避することです。 しかし、？-in-main自体が単調になると、機能全体が損なわれます。 本番コードなどでの使用を思いとどまらせるような結果は避けたいと思います。

私はこの機能をメインで使用しようとしてきましたが、かなりイライラすることがわかりました。 終了特性の既存の実装では、複数の種類のエラーを便利に「蓄積」することができません。たとえば、エラーを実装していないため、failure::Failを使用できません。 Boxが使えない、 同じ理由。 デバッグへの変更を優先する必要があると思います。 =）

Displayを使用する場合、 MainErrorのような高速でダーティなタイプを導入して、複数の種類のエラーを蓄積できます。

pub struct MainError {
    s: String,
}

impl std::fmt::Display for MainError {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        self.s.fmt(f)
    }
}

impl<T> From<T> for MainError where T: std::error::Error {
    fn from(t: T) -> Self {
        MainError {
            s: t.to_string(),
        }
    }
}

これにより、以下のようなBox<Error>のようなものが可能になります。

fn main() -> Result<(), MainError> {
    let _ = std::fs::File::open("foo")?;
    Ok(())
}

表示とデバッグの以前の説明は、 https： //github.com/rust-lang/rust/issues/43301#issuecomment -362020946から始まり、ここの隠れた部分にあります。

@BurntSushi私はあなたに同意します。 これを修正できない場合は、回避策があります。

use std::fmt;
struct DisplayAsDebug<T: fmt::Display>(pub T);

impl<T: fmt::Display> Debug for DisplayAsDebug {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        fmt::Display::fmt(&self.0, f)
    }
}

impl<T: fmt::Display> From<T> for DisplayAsDebug {
    fn from(val: T) -> Self {
        DisplayAsDebug(val)
    }
}

これがstd::fmtにある場合、次のようなものを使用できます。

use std::{fmt, io};

fn main() -> Result<(), fmt::DisplayAsDebug<io::Error>> {
    let mut file = File::open("/some/file")?;
    // do something with file
}

近い将来、これに貢献する時間はまだありませんが、メインの?は本格的なCLIプログラムで使用できるはずであり、元のドラフトには機能があったことにも同意します。それを容易にすることを目的としたRFC。 彼らは漸進主義の名の下に落とされましたが、多分彼らは再訪されるべきです。

多くのコードが安定版で使用される前に、これがすぐに行われる場合は、後方互換性のない方法でこれを修正することは問題ないと思います。

Rustで多くのCLIプログラムを作成し、Rustスタイルを担当している人として、私はここで@burntsushiにほぼ同意します。 私はRFCで指定されたこの機能のバージョンを喜んで使用したでしょう。

しかし、 Debugの実装をユーザーに表示することはバグであり、CLIプログラムのあらゆる場所でunwrapを呼び出すよりもはるかに優れているとは思いません。 したがって、サンプルコードでも、このバージョンの機能を使用することは想像できません。 mainから定型文を削除すると、新しいRust開発者の学習が簡素化され、 quick_main!または同等のものを説明する必要がなくなったため、これは残念です。

これを使用することを想像できるほとんどの状況は、doctestからunwrapを削除することです。 しかし、それがまだサポートされているかどうかはわかりません。

Displayを使用する場合、 MainErrorのような高速でダーティなタイプを導入して、複数の種類のエラーを蓄積できます。

個人的には、この種の回避策は十分な複雑さを追加するため、 ? -in- main完全に回避する方が簡単です。

@Aaronepower ：

私が知る限り（stdlibをコンパイルする時間がなく、スペシャライゼーションがこれをカバーしているかどうかわからないため、完全に間違っている可能性があります）、次のimplをTerminationに追加できない理由はありません。 これにより、表示が使用可能な場合は中断せずに使用でき、使用できない場合はデバッグにフォールバックできます。

これにより、 fn main() -> Result<(), failure::Error>を記述し、 Displayを使用して人間が読める形式のエラーを取得できるようになれば、私の主要な懸念事項は確実に満たされます。 ただし、これでも、 RUST_BACKTRACE=1が設定されている場合に、オプションでバックトレースをfailure::Errorに表示するという問題が残ると思いますが、それは範囲外である可能性があります。 failureで取り上げられます。

これはしばらく前に安定しましたが、 Resultの動作を実際に変更できるとは思いません。 私は個人的に、私が行う傾向のあるユースケース（高速でダーティなスクリプトなど）の現在の動作にかなり満足していますが、より複雑なスクリプトではそれを望まないことに同意します。 ただし、ディスカッションの時点で、その動作を制御できるいくつかの方法についても話し合いました（githubが私から物事を隠しているため、これらのコメントを今は見つけることができないようです）。

たとえば、エラータイプに独自の「ラッパー」を定義し、それにFromを実装できます。

struct PrettyPrintedError { ... }
impl<E: Display> From<E> for PrettyPrintedError { }

impl Debug { /* .. invoke Display .. */ }

これで、次のように書くことができます。つまり、 mainで?を使用できます。

fn main() -> Result<(), PrettyPrintedError> { ... }

おそらく、そのようなタイプはクイックCLIまたは何かの一部である必要がありますか？

@nikomatsakisええ、私は完全にその回避策を取得しますが、それは?-in-mainを使用するという簡潔さの目的を打ち負かすような気がします。 残念ながら、「この回避策を使用して?-in-mainを使用することは可能です」と、 ?-in-main自体が損なわれているように感じます。 たとえば、簡潔な例で回避策を書き出すつもりはありません。また、私が書くすべての例でquicliに依存するつもりもありません。 基本的に私が作成するすべてのCLIプログラムでエラーのDisplay出力が必要なため、クイックプログラムにも使用しません。 私の意見では、エラーのデバッグ出力は、ユーザーの前に置くCLIプログラムのバグです。

?-in-mainの代わりに、追加の〜4行関数があります。 したがって、 ?-in-mainを修正してDisplay $を使用するための回避策がそれよりもはるかに多い場合、個人的にはそれを使用する理由はほとんどありません（ドキュメントテストや単体テスト以外では、上記の通り）。

これはエディションで変更される可能性があるものですか？

@BurntSushi回避策がstdにあることについてどう思いますか？それで、 main()にもう少し長いreturn型宣言を書くだけで済みますか？

@Kixunil私の最初の気持ちは、それが口に合うかもしれないということです。 しかし、あまり考えていません。

@BurntSushi

?-in-mainの代わりに、追加の〜4行関数があります。

最終的には動作は安定しており、現時点では現実的に変更できるとは思いません。 （つまり、健全性違反などではありません。）

そうは言っても、現在の設定はDisplayよりもかなり素晴らしく、好ましいと思いますが、「デフォルト」をどのようにするかが問題だと思います。つまり、どちらの設定も次のように機能させることができます。その他、さまざまなニュータイプを介して。 したがって、デフォルトでは、 Debugを必要とする「quick-n-dirty」スクリプト、または洗練された最終製品を優先します。 洗練された最終製品は、追加のインポートをすぐに実行できる場所であり、さまざまな可能な形式から選択したい場所だと思う傾向があります（たとえば、エラーだけが必要なのか、argvを含めたいのか） [0]など）。

具体的には、次のようになります。

use failure::format::JustError;

fn main() -> Result<(), JustError> { .. }

または、別の形式を取得するには、おそらくこれを行います。

use failure::format::ProgramNameAndError;

fn main() -> Result<(), ProgramNameAndError> { .. }

これらは両方とも、以前に記述しなければならなかった4行の関数と比較してかなりいい感じです。

use std::sys;

fn main() {
  match inner_main() {
    Ok(()) => { }
    Err(error) => {
      println!("{}", error);
      sys::exit(1);
    }
}

fn inner_main() -> Result<(), Error> {
  ...
}

生産品質のために、出力のカスタムエラータイプに本質的に何を追加するかは、とにかく人々をプッシュするための良い方向のように思われるので、私はこのトピックに取り組んでいます。 これは、たとえば、 panic!がデフォルトでデバッグ品質のメッセージを提供する方法と平行しているようです。

@nikomatsakisそれはおそらくより良い長期的な見方であり、私はあなたの最終結果が食欲をそそるものだと思います。 これらのエラータイプがいつかstdになってしまうと、オーバーヘッドをできるだけ少なくして例で使用できるようになります。 :-)

プロセスノート：ここでは、最初のフィードバックを「すでに安定しているものを変更しましょう」ではなく「できることはありますか」で構成し、何かを求めるのではなく、高レベルの目標に焦点を当てようとしました。確かにできません。 :-)

それほど時間はかかりませんでした： https ：//crates.io/crates/exitfailure😆

Debugの特性とDisplayの特性を使用することで、どれだけの人が驚いているのだろうか。 最初のディスカッションドラフトと最終的なRFCはどちらもDisplayを使用しています。 これは、人々が1つのものを手に入れていると思っていたが、それが安定した後に別のものを手に入れていることを知っているという、普遍的なimpl特性の事件に似ています。 また、多くの人がこの機能を使用しないことに驚いていることを考えると、次のエディションでこの機能を変更しても、大きなバックスラッシュは発生しないと思います。

@WiSaGaN RFCの詳細は、随時変更される可能性があります。 これは期待され、健康的です。 RFCは設計ドキュメントであり、これからもこれからも完全に表現されたものではありません。 情報発見は大変で、これ以上注意を払わないのは私のせいです。 この機能の安定性を再検討することを避け、代わりに、実行可能に実行できるより高いレベルの目標に焦点を当てることができることを望んでいます。

@nikomatsakisクイックアンドダーティケースを好むことで私が目にする主な問題は、それらに対処する方法がすでにあるということです： .unwrap() 。 したがって、その観点からすると、 ?は、すばやく汚いものを書くためのもう1つの方法ですが、洗練されたものを書くための同様に簡単な方法はありません。

もちろん、船は出航したので、私たちはほとんどねじ込まれています。 可能であれば、これが次の版で変更されるのを楽しみにしています。

@Kixunil 、 unwrapは、問題に対処するための良い方法ではありません。このスレッドのタイトルには、 mainでシンタックスシュガー?を使用できるようにしたいと記載されているためです。 。 私はあなたがどこから来ているのか理解できますが（実際、オプション処理に?を使用することは私の最初の躊躇の一部でした）、言語に?が含まれているため、この問題はかなり良いユーザビリティが私見に勝ちます。 より良い出力が必要な場合は、オプションがあります。 最初にテストせずにユーザーにリリースすることはありません。 mainの出力にカスタムタイプが必要であることがわかります。

mainに?が欲しい「理由」については、今の奇妙さをよく考えてください。 実質的に他のどこでも使用できます（リターンタイプを制御できるため）。 main関数は、やや特別な感じになってしまいますが、そうすべきではありません。

.unwrap()は、構成されていない手っ取り早いソリューションであるため、プログラムをスケッチしているときに、コードをmain()に出し入れすることはできません。

比較すると、 ?は構成を行う迅速で汚いソリューションであり、迅速で汚くないようにすることは、正しいreturn-typeをmain()に置くことの問題であり、コード自体を変更します。

@Screwtapelloああ、今それは私には理にかなっています。 ありがとう！

これの目的は、追加のラッパーを使用せずに、すべてのアプリケーションに?をmainに含めることだと思ったことを表現したいと思います...テストのためだけの場合は、それに多くの利点があり、悲しいことに.unwrap()に固執し続けるでしょう。

@oblitumテストだけではありません。 （デフォルトでは） Display形式を使用することはありません。 これは、探している出力である場合とそうでない場合がありますが、 .unwrapの出力よりもほぼ間違いなく優れています。 そうは言っても、 ?を使用すると、コードが「より洗練された」ものになる可能性があります。 いずれにせよ、 @ nikomatsakisが上で詳述したように、 mainの?エラーの出力をカスタマイズすることはまだ可能です。

陳列ケースのstdlibにニュータイプを導入することは可能でしょうか？ 何かのようなもの：

#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[must_use]
struct DisplayResult<E: fmt::Display>(Result<(), E>)

impl<E> Termination for DisplayResult<E> {
    // ... same as Result, but use "{}" instead of "{:?}"
}

impl<E> From<Result<(), E>> for DisplayResult<E> {}
impl<E> Deref<Result<(), E>> for DisplayResult<E> {}
impl<E> Try for DisplayResult<E> {}
// ...

これにより、ユーザーは次のように書くことができます。

fn main() -> DisplayResult<MyError> {
    // Ordinary code; conversions happen automatically via From, Try, etc.
}

ここでの主な動機は次のとおりです。

• エラーが返されたときに表示が使用されます
• ユーザーは、エラーや結果の種類を余分に折り返す必要はありません。 メイン関数で?を使用できます。

フォローアップ： ?とFromのセマンティクスでは、これが暗黙的に機能しない場合があります。 ?がFromを介してエラータイプ間で変換されることは知っていますが、 Tryのさまざまな実装者に対して同じことを行うかどうかはわかりません。 つまり、 Result<?, io::Error>からResult<?, FromIoError>に変換されますが、必ずしもResult<?, Err>からDisplayResult<Result<?, Err>>に変換されるとは限りません。 基本的に、私はこのようなものが機能することを探しています：

fn main() -> DisplayResult<io::Error> {
    let f = io::File::open("path_to_file")?;
    let result = String::new();
    f.read_to_string(result)?
}

これが機能しないと仮定すると、おそらく代わりに、Cargo.tomlで単純な条件付きコンパイルフラグを作成できますか？

@Lucretiel ：プログラマーは主に終了メッセージをコンソールに出力したいと思っているようです。 これは、非技術的なデスクトップアプリケーション、ロギング配管を備えたデーモンなどには当てはまりません。私は、標準ライブラリに「一般的に有用な」ものを、そこにあるはずの説得力のある証拠（数字など）なしで追加しないことを好みます。

main Result<(), E> where E: Errorを返すプログラマーは、エラーメッセージをコンソールに出力することに関心があると思います。 Debugを介して出力される現在の動作でさえ、「コンソールに終了メッセージを出力する」です。

このスレッドでは、stderrに何かを印刷する必要があるという幅広い合意があるようです。 重要な決定は、「 "{}"または"{:?}" 、あるいは他の何かで印刷するかどうか、そしてもしあれば、それをどのように構成できるか」です。

@Lucretiel 、私にとって、 Resultを返すことの価値は、終了ステータスをうまく制御しています。 パニックハンドラーに任せておくのが最善ではないものを印刷するかどうか。 stderrに何かを印刷するかどうかだけでなく、何を印刷するか（バックトレース、エラーメッセージなど）の問題もあります。 https://github.com/rust-lang/rust/issues/43301#issuecomment -389099936、特にを参照してください。 最後の部分。

私は最近これを使用し、 Displayと呼ばれることを望みました。 ここで間違った電話をかけたことは間違いありません。

私が気付いたプロセスの失敗は、決定がlibsチームではなくlangチーム（主にNikoと私）によって行われたことですが、問題のコードは完全にstdにあります。 おそらく、libsはより良い決定を下したでしょう。

@withoutboats変更するには遅すぎますか？ ドキュメントでは、この機能がまだ夜間のみ/実験的としてタグ付けされていることに気付きましたが、安定化プロセスの背後にある粒度の一部を理解していない可能性があります。

私もこの変更を望んでおり、チームが実装をDisplayからDebugに変更するように依頼したときに、この変更を強く支持していなかったことを後悔しています。

@Lucretiel Termination特性は毎晩ですが、機能自体（ main Termination実装を返す）はすでに安定しています。

特性の名前を安定させるためのチケットまたはタイムラインはありますか？

@xfixこれは、実装を変更できることを意味しますよね？ 動作は変更されませんが（ Terminationはmainから返されます）、トレイト自体は次のように変更されます。

impl<E: Debug> Termination for Result<(), E> ...

に：

impl<E: Display> Termination for Result<(), E> ...

実装を変更することは可能ですよね？

下位互換性を壊さずにはいられません。 このコードは、今日の安定したRustでコンパイルされます。

#[derive(Debug)]
struct X;

fn main() -> Result<(), X> {
    Ok(())
}

Displayを要求するという提案された変更により、コンパイルが停止します。

すでに述べたように、特殊化のようなものが役立つ可能性がありますが、特殊化についての私の現在の理解は、 DisplayとDebugの両方を実装するタイプにのみ役立つということです（つまり、より特別な1つの実装）。

trait ResultTerm {
    fn which(&self);
}
impl<T: Debug> ResultTerm for T {
    default fn which(&self) {
        println!("{:?}", self)
    }
}
impl<T: Debug + Display> ResultTerm for T {
    fn which(&self) {
        println!("{}", self)
    }
}

enum MyResult<T, E> {
    Ok(T),
    Err(E),
}

impl<T, E> Termination for MyResult<T, E>
where
    E: ResultTerm,
{
    fn report(self) -> i32 {
        match self {
            MyResult::Err(e) => {
                e.which();
                1
            }
            _ => 0,
        }
    }
}

遊び場

これはすべての一般的なケースをカバーするのに十分かもしれませんが、専門分野を公開しています。

ああ、安定したさびについてあなたが何を意味するのかわかります。 どういうわけか、これが安定して利用可能であることに気づいていませんでした。

これは、コンパイル時にCargoフラグを使用して切り替えることができるものですか？ panic = "abort"のように、他のものを切り替えることができるのと同じように。

多分？ 別のRustエディションのmain ?に対して異なる動作をすることが可能であることがわかりました。 おそらく2018年ではないかもしれませんが、おそらく2021年ですか？

同じプログラム内の異なるクレートは異なるエディションにある可能性がありますが、同じstdを使用するため、 stdで使用可能な特性とその実装は、エディション間で同じである必要があります。 理論的には（私はこれを支持していませんが）、$＃ main() TerminationとTermination2 $の2つの特性があり、1つまたはその他は、 main()を定義するクレートのエディションによって異なります。

何も非推奨にする必要はないと思います。 現在の状況が本番ユーザーに不満を持っているのと同じように、ディスプレイタイプのみに制限すると、クイックスクリプトユーザー（デバッグの派生は簡単ですが、ディスプレイの実装はそうではありません）を不満にするのに役立つ可能性があるという@Aaronepowerの感情をエコーし​​ます。 できたとしても、最終的にはメリットがないと思います。 @shepmasterによって提示された特殊化アプローチは、次の動作を作成するという点で有望だと思います。

1. デバッグはあるが表示はないタイプは、デフォルトでデバッグ出力が出力されます
2. デバッグと表示の両方があるタイプでは、デフォルトで表示出力が出力されます
3. 表示はあるがデバッグはないタイプは、コンパイラエラーになります

誰かがポイント2に反対するかもしれません。あなたがディスプレイ付きのタイプを持っていても、何らかの理由でデバッグを出力したい場合です。 このケースは、さまざまな事前に設計された出力形式のエラータイプ（特殊なルートを使用する場合でも、おそらく調査する価値があります）のNikoの提案によって対処されると思います。

ポイント3に関しては、少しぎこちないですが（1.0でtrait Display: Debugを実行する必要があったのではないでしょうか？）、誰かがDisplay implを作成するのに苦労した場合は、彼らに平手打ちを依頼することはあまりありません。単一の派生物（おそらく、とにかく持っていると思います...原則として、表示タイプにデバッグを設定することに反対する人はいますか？）。

ディスプレイタイプのみに制限すると、クイックスクリプトユーザーの不満につながる可能性があります（デバッグの導出は簡単ですが、ディスプレイの実装は簡単ではありません）

クイックスクリプトでDebugよりもDisplayの方が望ましい場合は、エラータイプとして&'static strまたはStringを使用します。 #[derive(Debug)]を叩くカスタムエラータイプがある場合は、エラー処理に取るに足らないエネルギーをすでに費やしています。

@SimonSapinクイックスクリプト環境では好ましくないとは言えませんが、努力をせずに文字列をDisplay形式で印刷したいという立場に立つほどは好ましくありません。エラーを適切にフォーマットするには、 Debugをお勧めします。これは、文字列の場合のエラーフォーマットが適切に形成されていないため、 Err("…")を囲むと、他のエラーから簡単に視覚的に識別できるためです。放出された可能性のある出力。

FWIWでフォーマットされるのは、 Result<_, E>値ではなく、内部のE値のみです。 したがって、出力にErr(は表示されません。 ただし、現在のコードはError:プレフィックスを追加します。これは、おそらくDisplayが使用された場合に残ります。 引用符を出力しないことに加えて、 Displayは文字列の内容をバックスラッシュエスケープしません。これは、ユーザーに（エラー）メッセージを表示する場合に望ましいIMOです。

https://github.com/rust-lang/rust/blob/cb6eeddd4dcefa4b71bb4b6bb087d05ad8e82145/src/libstd/process.rs#L1527 -L1533

状況を考えると、私たちができる最善のことは、 Display + Debugを実装してDisplay implを出力する型に特化することだと思います。 Debugを実装しない型は（交差点の実装をサポートするまで）エラーとして使用できないのは残念ですが、最善を尽くすことができます。

主な質問は、そのimplがstdの特殊なimplに関する現在のポリシーに該当するかどうかです。 通常、特殊化はstdでのみ使用するという規則があります。この場合、動作が後で変更されないという安定した保証は提供されません（特殊化自体は不安定な機能であるため）。 最終的に機能としての特殊化を削除すると、いつかこれらのタイプがDebug出力の印刷に戻る可能性があることを認識して、このimplを提供しても問題ありませんか？

実は、このスペシャライゼーションは、不健全さを導入するために使用される可能性があるため、現時点では許可できないと思います。 このimplは、実際には非常に多くの問題を引き起こす種類の特殊化です。

use std::cell::Cell;
use std::fmt::*;

struct Foo<'a, 'b> {
     a: &'a Cell<&'a i32>,
     b: &'b i32,
}

impl<'a, 'b> Debug for Foo<'a, 'b> {
    fn fmt(&self, _: &mut Formatter) -> Result {
        Ok(())
    }
}

impl<'a> Display for Foo<'a, 'a> {
    fn fmt(&self, _: &mut Formatter) -> Result {
        self.a.set(self.b);
        Ok(())
    }
}

スペシャライゼーションが現在機能している方法のため、 Foo<'a, 'b>で$ reportを呼び出すことができます。ここで、 'bは'aよりも長持ちしません。現在、コンパイラーは完全に可能です。ライフタイム要件が満たされていない場合でもDisplayインスタンスを呼び出すimplを選択し、ユーザーが参照のライフタイムを無効に延長できるようにします。

皆さんのことはわかりませんが、簡単な「スクリプト」を書くときは、すべてのことからunwrap()だけです。 コンテキスト情報を提供するバックトレースがあるため、100倍優れています。 これがないと、コードにlet ... = File::open()が複数ある場合、どちらが失敗したかを特定できません。

皆さんのことはわかりませんが、簡単な「スクリプト」を書くときは、すべてのことからunwrap()だけです。 コンテキスト情報を提供するバックトレースがあるため、100倍優れています。 これがないと、コードにlet ... = File::open()が複数ある場合、どちらが失敗したかを特定できません。

これが実際に私がDisplayについて非常に強く感じる理由です。なぜなら、この場合、一般的に私が行うのは、ファイル名とその他の関連するコンテキスト情報を添付するmap_errを実行することだからです。 私の経験では、一般的に、デバッグ出力は実際に何がうまくいかなかったかを追跡するのにあまり役立ちません。

@Kixunil ：あるいは、より複雑なエラー処理戦略および/またはより広範なロギングおよび/またはデバッグを希望します。

「RFCを実装する」にチェックマークを付けることができると思いますよね？ 少なくともこれによると！ ：笑顔：

これが完全に無知である場合はご容赦ください。ただし、可能であれば、特殊化を使用してエラーチェーンを報告することはできません。

use std::error::Error;

impl<E: fmt::Debug> Termination for Result<!, E> {
    default fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {:?}", err);
        ExitCode::FAILURE.report()
    }
}

impl<E: fmt::Debug + Error> Termination for Result<!, E> {
    fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {:?}", err);

        for cause in Error::chain(&err).skip(1) {
            eprintln!("Caused by: {:?}", cause);
        }
        ExitCode::FAILURE.report()
    }
}

https://github.com/rust-lang/rfcs/blob/f4b8b61a414298ba0f76d9b786d58ccdc34a44bb/text/1937-ques-in-main.md#L260 -L270

impl<T: Termination, E: Display> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(ref err) => {
                print_diagnostics_for_error(err);
                EXIT_FAILURE
            }
        }
    }
}

RFCのこの部分が実装されなかった理由はありますか？

使用する特性と実装の正確なセットにいくつかの変更を加えましたが、現時点では詳細を思い出せません。安定させるために残っている詳細がいくつか残っていると思います。 詳細については、トップ号からリンクされている安定化レポートを確認することをお勧めします。

この機能のステータスは何ですか？ 安定化の提案はありますか？

@GrayJackかなり前に問題が発生したため、この問題は解決する必要があります。

確かに、少し混乱しましたTerminationトレイトのリンクからここにアクセスしましたが、それについて質問していましたが、 termination_trait_libに適切な問題がありますか？

この問題は解決する必要があります

この問題は、 Terminationの安定化を追跡するためにまだ開いています。