付随するRFCは、ラベル付きのreturn / breakに基づく脱糖について説明していますが、それも取得していますか、それともコンパイラで?とcatchに特別な処理がありますか？

編集：ラベル付きのreturn / breakは、 ?やcatchと

ラベル付きの返品/休憩は、純粋に説明を目的としています。

3時56 PMで金、2016年2月5日には、ジョナサン・リーム[email protected]
書きました：

付随するRFCは、ラベル付きのリターン/ブレークに基づく脱糖について説明しています。
私たちもそれを手に入れていますか、それとも特別な治療がありますか？ そして
コンパイラをキャッチしますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/rust-lang/rust/issues/31436#issuecomment-180551605 。

安定化する前に解決しなければならないもう1つの未解決の質問は、 Into implが従わなければならない契約はどうあるべきか、またはIntoが使用するのに適切な特性であるかどうかです。ここでのエラーアップキャストについて。 （おそらくこれは別のチェックリスト項目である必要がありますか？）

@reem

ラベル付きのreturn / breakは優れたアイデアだと思います...おそらく別のRFCを開きます。

してください！

Carrier特性について、RFCプロセスの初期に書き戻したそのような特性の要点の例を次に示します。
https://gist.github.com/thepowersgang/f0de63db1746114266d3

これは解析中にどのように扱われますか？

struct catch {
    a: u8
}

fn main() {

    let b = 10;
    catch { a: b } // struct literal or catch expression with type ascription inside?

}

@petrochenkovええと、定義は構文解析に影響を与えることはできませんでしたが、 { 、この場合は:後の2番目のトークンに基づいて、先読みルールがまだあると思います。構造体リテラルとして解析されます。

また

let c1 = catch { a: 10 };
let c2 = catch { ..c1 }; // <--

struct catch {}
let c3 = catch {}; // <--

+ https://github.com/rust-lang/rfcs/issues/306 if（when！）implemented。
構造体リテラル以外に競合はないようです。

上記の例を考えると、私は（いつものように）最も単純な解決策を求めています-常に式の位置のcatch {をcatchブロックの開始として扱います。 とにかく誰も彼らの構造をcatchとは呼びません。

catch代わりにキーワードを使用した方が簡単です。

これはキーワードリストです： http ：

@blussええ、私はそれらのどれも素晴らしいものではないことを認めます... overrideは近い唯一のもののようです。 または、 do使用することもできます。 または組み合わせですが、すぐに素晴らしいものは見つかりません。 do catch ？

doは、IMOに近いと思われる唯一のものです。 接頭辞としてdoが付いたキーワードスープは少し不規則で、言語の他の部分とは異なりますか？ while letもキーワードスープですか？ あなたがそれに慣れているとき、それは今大丈夫だと感じます。

try!を使用するためのポート?

?を移植して、代わりにtry!を使用することはできませんか？ これにより、デバッグ時など、 Resultリターンパスを取得するユースケースが可能になります。 try!これはかなり簡単です。ファイルの先頭（またはlib / main.rs）でマクロをオーバーライドするだけです。

macro_rules! try {
    ($expr:expr) => (match $expr {
        Result::Ok(val) => val,
        Result::Err(err) => {
            panic!("Error occured: {:?}", err)
        }
    })
}

Resultリターンパスで最初に出現したtry!から始まるパニックスタックトレースを取得します。 実際、 return Err(sth)代わりにエラーを発見した場合にtry!(Err(sth))実行すると、完全なスタックトレースを取得することさえできます。

しかし、そのトリックを実装していない人々によって書かれた外国のライブラリをデバッグするとき、チェーンのどこかでtry!使用法に依存します。 そして今、ライブラリがハードコードされた動作で?演算子を使用している場合、スタックトレースを取得することはほとんど不可能になります。

try!をオーバーライドすると、 ?演算子にも影響するので便利です。

後でマクロシステムがより多くの機能を取得すると、パニックになることさえあります！ 特定のタイプのみ。

この提案でRFCが必要な場合は、お知らせください。

理想的には、 try!をオーバーライドする機能に依存するのではなく、 ?拡張してスタックトレースサポートを直接提供することができます。 その後、それはどこでも動作します。

スタックトレースはほんの一例です（非常に便利なものですが、私には思えます）。
キャリア特性が機能するように作られている場合、おそらくそれはそのような拡張をカバーすることができますか？

2016年2月7日午後4時14分、ラッセルジョンストン[email protected]
書きました：

理想的には？ スタックトレースのサポートを直接提供するように拡張することもできますが、
try！をオーバーライドする機能に依存するのではなく。 その後、それはうまくいくでしょう
どこにでも。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/rust-lang/rust/issues/31436#issuecomment-181118499 。

推測したくはありませんが、いくつかの問題はありますが、うまくいくと思います。

Result<V,E>値を返すコードがある通常のケースを考えてみましょう。 ここで、 Carrierトレイトの複数の実装が共存できるようにする必要があります。 E0119に遭遇しないようにするには、すべての実装をスコープ外にする必要があり（おそらく、デフォルトではインポートされないさまざまな特性を介して）、 ?演算子を使用する場合、ユーザーは希望するものをインポートする必要があります実装。

これには、デバッグしたくない人でも、 ?を使用するときに、希望する特性の実装をインポートする必要があります。事前定義されたデフォルトのオプションはありません。

すべてのタイプが範囲外であるResult<V,E>に対してカスタムCarrier実装を実行したい場合は、おそらくE0117も問題になる可能性があるため、libstdはすでにCarrier実装セットを提供する必要があります。最も使用されているユースケースのpanic! ingの実装、おそらくそれ以上）。

マクロを介してオーバーライドする可能性があると、元の実装者に追加の負担をかけることなく、柔軟性が向上します（希望する実装をインポートする必要はありません）。 しかし、rustにはこれまでマクロベースの演算子がなかったこと、そしてcatch { ... }が機能するはずの場合、少なくとも追加の言語項目がなければ、マクロを介して?を実装することは不可能であることもわかりました（ return_to_catch 、 throw 、RFC 243で使用されているparamでbreakとラベル付けされています）。

非常に少量のコードを変更するだけで、できればファイルの先頭で、 Errリターンパスを使用してResultスタックトレースを取得できるようにするセットアップは問題ありません。 このソリューションは、 Errタイプが実装される方法と場所に関係なく機能する必要もあります。

バイクシェディングにチャイムを入れるだけです。 catch in { ... }はかなりうまく流れます。

catch! { ... }は別のバックコンパットの選択肢です。

また、これによって何かが変わるとは思いませんが、タイプの帰属が$i:ident : $t:ty壊したのと同じように、 $i:ident ?を受け入れていたマルチアームマクロを壊してしまうことに注意してください。

下位互換性をやり過ぎないでください。 catch後に{続く場合は、キーワードとして扱います（おそらく式の位置のみですが、互換性に関して大きく変化するかどうかはわかりません）。

また、構造体リテラルを含まないいくつかの考えられる問題を想像することもできます（例： let catch = true; if catch {} ）。 しかし、私はもっと醜い構文よりもマイナーな重大な変更を好みます。

とにかく、新しいキーワードを追加するためのはありませんでしたか？ 新しい構文のために、ある種のfrom __future__オプトインを提供することができます。 または、コマンドライン/Cargo.tomlでRust言語のバージョン番号を指定します。
長期的には、すでに予約されているキーワードのみを処理できるかどうかは非常に疑わしいです。 コンテキストに応じて、キーワードにそれぞれ3つの異なる意味を持たせたくありません。

同意する。 これは、これが登場した最初のRFCでもありません（https://github.com/rust-lang/rfcs/pull/1444は別の例です）。 それが最後ではないと思います。 （https://github.com/rust-lang/rfcs/pull/1210のdefaultも、私が支持しているRFCではありませんが。）追加する方法を見つける必要があると思います。すべての新しいケースの文法をアドホックにハックする方法を理解しようとするのではなく、神に正直なキーワード。

1.0より前のいくつかのキーワードを予約しないという議論全体が、言語に互換性を持たせて（おそらく明示的にオプトインすることによって）新しいキーワードを後方に追加する方法を確実に導入するということではなかったので、意味がありませんでしたか？ 今はいい時期だと思います。

@japaric古いPRを復活させてこれを引き継ぐことに興味がありますか？

@aturon私の実装は、 try!(foo)と同じ方法でfoo?を単純に脱糖しました。 また、メソッドと関数の呼び出しでのみ機能しました。つまり、 foo.bar()?とbaz()?機能しますが、 quux?と(quux)?は機能しません。 それは最初の実装で大丈夫でしょうか？

@japaricメソッドと関数呼び出しに制限した理由は何ですか？ 一般的な接尾辞演算子として解析する方が簡単ではないでしょうか。

メソッドと関数呼び出しに制限する理由は何でしたか？

?拡張をテストする（私にとって）最も簡単な方法

一般的な接尾辞演算子として解析する方が簡単ではないでしょうか。

多分

@japaric （ @eddybが示唆しているように）完全な接尾辞演算子に一般化するのはおそらく良いこと?を着陸させ、後でcatch追加するの

@aturon了解しました。誰も私に勝てない場合は、来週までにPostfixバージョンを調べます:-)。

＃31954で私のPRをリベース/更新しました:-)

スタックトレースを提供するためのサポートはどうですか？ それは計画されていますか？

私は+1の男になるのは嫌いですが、スタックトレースは、過去の私の時間のかなりの部分を節約しました。 たぶんデバッグビルドで、そしてエラーパスにぶつかったとき、？ オペレーターはファイル/行を結果のVecに追加できますか？ たぶん、Vecもデバッグ専用である可能性がありますか？

そして、それは公開されるか、エラーの説明の一部に変わる可能性があります...

Option<Result<T, E>>返すイテレータ内でtry! / ?を使用したいという状況に遭遇し続けます。 残念ながら、それは現在実際には機能しません。 これをサポートするためにキャリア特性が過負荷になる可能性があるのでしょうか、それともより一般的なFromに入るのでしょうか？

@hexsel Result<>タイプがデバッグで命令ポインタのvecを運ぶことを本当に望んでいますか？ それに追加します。 そうすれば、DWARF情報を使用して読み取り可能なスタックトレースを構築できます。

@mitsuhikoしかし、どうすればResultを作成してパターンマッチングできますか？ それは_ちょうど_ enum atmです。

Optionラッピングについては、 Some(catch {...})が必要だと思います。

現在、私の習慣は今やっているtry!(Err(bla))の代わりにreturn Err()私は1つでオン後にトライマクロを無効にすることができますように、そのパニック、バックトレースを取得するためです。 それは私にとってはうまく機能しますが、私が扱うコードは非常に低レベルであり、ほとんどの場合エラーが発生します。 Resultを返す外部コードを使用する場合でも、 ?を回避する必要があります。

@eddybは、他の方法で操作する必要があることに加えて、非表示の値を運ぶための言語サポートが必要になります。 他の方法でできるのかと思っていたのですが、どうしたらいいのかわかりません。 他の唯一の方法は、追加のデータを含めることができる標準化されたエラーボックスでしたが、ボックス化されたエラーを持つ必要はなく、ほとんどの人はそれを行いません。

@mitsuhiko ErrorトレイトとTLSの新しい（デフォルトの）メソッドを考えることができます。
後者は時々消毒剤によって使用されます。

@eddybは、結果を識別でき、ボックス化する必要がある場合にのみ機能します。そうしないと、スタックを上に移動するときにメモリ内を移動します。

@mitsuhiko TLS？ 実際には、エラーを値で比較できる必要があります。

または、タイプ（ From入力と出力をリンクする）だけでも、スタックトレースが必要な同時エラーの数を同時に伝播する必要がありますか？

より単純なソリューションが機能する場合、個人的にResult固有のコンパイラハックを追加することには反対です。

@eddybエラーはスタックを上向きに渡します。 必要なのは、発信元だけでなく、すべてのスタックレベルでのEIPです。 また、エラーはa）現在比較できず、b）比較が等しいからといって、同じエラーであるとは限りません。

スタックトレースが必要な同時エラーの数を同時に伝播する必要があります

エラーはすべてキャッチされ、別のエラーとして再スローされます。

より単純なソリューションが機能する場合、個人的に結果固有のコンパイラハックを追加することには反対です。

より単純なソリューションがどのように機能するかはわかりませんが、何かが足りない可能性があります。

?ごとに命令ポインタを保存し、それをエラータイプと関連付けることができます。
「エラーはすべてキャッチされ、別のエラーとして再スローされました。」 しかし、その情報がResultに隠されている場合、どのようにその情報を保存しますか？

しかし、結果に隠されている場合、その情報をどのように保存しますか？

その情報を結果に保存する必要はありません。 ただし、保存する必要があるのは、障害の原因の一意のIDであるため、相互に関連付けることができます。 また、エラートレイトは単なるトレイトであり、ストレージがないため、代わりに結果に保存できます。 命令ポインタvec自体は、結果に格納する必要はなく、TLSに送信される可能性があります。

1つの方法は、結果failure_id(&self)メソッド

結果がスタックを上向きに通過するときに、コンパイラが通過するスタックフレームを記録する命令を挿入する必要があるため、これには言語サポートが必要になります。 したがって、結果の戻り値は、デバッグビルドでは異なって見えます。

「コンパイラは、フォールスルーしたスタックフレームを記録する命令を挿入します」-しかし、 ?は明示的であり、これは例外のようなものではありません。または、通過した?記録するのは好きではありませんか？

とにかく、手動でエラーを解凍してからErrに戻すと、そのIDはどのように保持されますか？

「そして、エラー特性は単なる特性であり、ストレージがないため、代わりに結果に格納される可能性があります」
これにはバリアントがあります。 Errorトレイトの実装は、コンパイラで特殊なケースを使用して型に整数フィールドを追加し、型を作成するとIDが生成され、コピー/ドロップするとrefcountを効果的にインクリメント/デクリメントします（ Result::unwrapが使用されていない場合は、最終的にTLSの「実行中のエラーセット」からそれをクリアします）。

しかし、それはCopy特性と矛盾します。 つまり、 ?または他の特定のユーザーアクションによってトリガーされない特別な動作をResultに追加すると、 Copy不変条件が無効になる可能性があります。

編集：この時点で、そこにRc<ErrorTrace>を埋め込んだ方がよいでしょう。
EDIT2 ：私が言っていることですが、 catch関連するエラートレースをクリアできます。
EDIT3 ：実際、ドロップ時に、以下のより良い説明を参照してください。

「コンパイラは、フォールスルーしたスタックフレームを記録する命令を挿入します」-しかし？ 明示的です、これは例外のようなものではありません、またはあなたは？だけを記録するのが好きではありませんか？ 通過した？

?使用しないフレームが多すぎるため、これは機能しません。 言うまでもなく、すべての人が?だけでエラーを処理するわけではありません。

とにかく、手動でエラーを解凍してからErrに戻すと、そのIDはどのように保持されますか？

そのため、コンパイラのサポートが必要になります。 コンパイラーは、結果であるローカル変数を追跡する必要があり、再ラップのために結果IDを先に伝播するのが最善です。 これが魔法すぎる場合は、操作のサブセットに制限される可能性があります。

?使用しないフレームが多すぎるため、これは機能しません。 言うまでもなく、すべての人が?だけでエラーを処理するわけではありません。

さて、 Resultを返すことは、複数のリターンパスを持つ複雑な関数で直接特殊なケースになっていることがわかりました（そのうちのいくつかは?からの早期リターンです）。

これが魔法すぎる場合は、操作のサブセットに制限される可能性があります。

または完全に明示的にしました。 コンパイラによって魔法のように追跡する必要がある非?再ラッピングの例はありますか？

@eddybエラーを手動で処理する一般的なケースは、サブセットを処理するIoErrorです。

loop {
  match establish_connection() {
    Ok(conn) => { ... },
    Err(err) => {
      if err.kind() == io::ErrorKind::ConnectionRefused {
        continue;
      } else {
        return Err(err);
      }
    }
  }
}

@mitsuhiko次に、IDをio::Error内に保持することは間違いなく機能します。

要約すると、TLSのVec<Option<Trace>> 「スパース整数マップ」はstruct ErrorId(usize)でキー設定され、3つのlangアイテムでアクセスされます。

• fn trace_new(Location) -> ErrorId 、 constエラー値を作成する場合
• fn trace_return(ErrorId, Location) 、関数_declared_から-> Result<...>として戻る直前（つまり、その_happens_がResult型で使用されるという戻り値のジェネリック関数ではありません）
• fn trace_destroy(ErrorId) 、エラー値をドロップする場合

変換がMIRで実行される場合、 Locationは、エラー値の構築またはLvalue::Returnへの書き込みのいずれかをトリガーする命令のSpanから計算できます。これは、はるかに信頼性が高くなります。命令ポインタIMOよりも（とにかくLLVMでそれを取得する簡単な方法はありません。特定のプラットフォームごとにインラインasmを発行する必要があります）。

@eddyb

それはバイナリサイズの膨満感につながりませんか？

@ arielb1デバッグモードでは、debuginfoがバイナリを肥大化させる場合にのみ実行します。debuginfoを巧妙に再利用することもできます_shrug_。

@eddybその場合の場所は何ですか？ IPを読むのが難しいのは何かわからない。 もちろん、ターゲットごとにカスタムJSが必要ですが、それはそれほど難しいことではありません。

@mitsuhikoこれは、オーバーフローチェックやその他のコンパイラが発するパニックに使用するのと同じ情報である可能性があります。 core::panicking::panic参照してください。

スタックがほどけているのに、なぜこれほど多くのスタック情報をError / Resultパックするのですか？ スタックがまだある間にコードを実行しないのはなぜですか？ たとえば、スタックのパス上の変数に関心がある場合はどうなりますか？ Errが呼び出されたときに、ユーザーがカスタムコードを実行できるようにするだけです。たとえば、選択したデバッガーを呼び出すことができます。 これは、（オーバーライド可能な）マクロであるためにtry!すでに提供しているものです。 最も簡単な方法は、適切なパラメータでプログラムを開始した場合にスタックを出力するErr場合にパニックを起こすことです。

tryを使用すると、 Err場合に必要なことをすべて実行できます。また、マクロクレート全体をオーバーライドしたり、エラーの再現が困難な場合やパフォーマンスが重要なコードに触れないようにスコープを設定したりできます。パフォーマンスクリティカルなコードをたくさん実行する必要があります。

実際の情報は破壊されるため、蓄積された人工スタックに情報の一部を保存する必要はありません。 マクロのオーバーライド方法はすべて、次の方法で改善できます。

• ?も同様の方法でオーバーライドできます。最も簡単な方法は、 ?をtry!砂糖として定義することです。特に、クレートの境界で発生しないエラーをキャッチするために必要です。上記の私のコメントで概説されています。
• さらに柔軟性を持たせるために、型の照合など、より強力なマクロシステムを使用します。 はい、これを従来の特性システムに組み込むことを考えることもできますが、錆は特性の実装をオーバーライドできないため、少し複雑になります

@ est31スタックは、パニックのように_自動的に_「巻き戻され」ません。これは、早期リターンのための構文糖衣です。
はい、ブレークポイントを設定できる固定名の空の関数の呼び出しをコンパイラーに挿入させることができます。これは非常に簡単です（また、 call dump(data)などの情報もあります。ここでdumpとdataは、デバッガーが見ることができる引数です）。

@eddyb空の関数では、たとえば、大規模なデプロイメントでいくつかの「カナリア」デバッグインスタンスを保持してエラーがログに表示されるかどうかを確認し、戻って修正するなどのユースケースは許可されないと思います。 反応的よりも積極的であることが望ましいことは理解していますが、すべてを予測するのは簡単ではありません

@hexselそうです。そのため、 Result::unwrapまたは新しいignoreメソッド（または常にエラーをドロップする場合でも）がトレースをstderrにダンプするTLSベースのメソッドを好みます。

@eddyb TLSのデータ構造のようなスタックに、命令ポインターまたは値から派生したものを追加すると、基本的に、実際のスタックの小さなバージョンが再構築されます。 リターンはスタックを1エントリ減らします。 したがって、スタックの_unwind_部分を返すときにこれを行うと、RAM内の他の場所で限定バージョンをビルドします。 おそらく「アンワインド」は「合法的な」リターンから生じる動作の間違った用語ですが、すべてのコードが?またはtry!を実行し、最後にインターセプトした場合、最終結果は同じです。 rustがエラー伝播を自動化しないのは素晴らしいことです。Javaがthrowsキーワードの後に​​すべての例外をリストする必要がある方法が本当に気に入りました。rustはそれを改善するのに適しています。

@hexselをオーバーライドする（ try!ですでに存在しているため）ベースのアプローチでは、これが可能になります。任意のコードを実行して、任意のログシステムにログを記録できます。 ただし、複数のtryがスタックを伝播するときに同じエラーをキャッチする場合は、「重複」を検出する必要があります。

@ est31 try!オーバーライドは、独自のコードでのみ機能します（文字通りマクロインポートシャドウイングです）。「弱いlangアイテム」のように別のものにする必要があります。

@ est31これは実際には正しくありません（巻き戻しについて）。 Result移動する必要がないため、トレースと実際のスタックは必ずしも関係がありません。元のバックトレースで上昇する必要はありません。横にも。
また、バイナリが最適化されている場合、バックトレースのほとんどがなくなり、デバッグ情報がない場合は、 Locationが厳密に優れています。 すべてのソース情報を、クローズドソース製品の開発者が照合できるランダムなハッシュに置き換える難読化プラグインを実行することもできます。

デバッガーは便利です（余談ですが、 lldbのよりクリーンなバックトレース出力が大好きです）が、万能薬ではありません。パニックに関する情報をすでに出力しているので、次のような手がかりを得ることができます。どうしたの。

それについて- {Option,Result}::unwrap追加の型引数があり、デフォルトで関数が呼び出された場所に依存する型になり、それらからのパニックが発生するような型システムレベルのトリックについていくつか考えましたより便利な位置情報。

値のパラメータ化が進んでいるので、それはまだオプションかもしれませんが、それだけではありません。 Resultトレースを完全に却下したくはありません。代わりに、_実装可能な_モデルを見つけようとしています。

try!オーバーライドすることは、独自のクレート内に含まれているため、まったく解決策ではありません。 これは、デバッグの経験としては受け入れられません。 私はすでに現在のtry!に対処しようとしてそれをたくさん試しました。 特に、多くの箱が関係していて、スタックを通過する途中でエラーが複数回変換される場合、エラーの発生場所とその理由を特定することはほぼ不可能です。 そのようなバンドエイドが解決策である場合、大規模なRustプロジェクトの一般的なエラー処理を再検討する必要があります。

@eddybでは、ファイル名、関数名、行番号、列番号をそのベクトルに文字通り埋め込むという提案はありますか？ 特にその情報はすでにDWARFではるかに処理可能な形式で含まれているため、これは非常に無駄に思えます。 また、DWARFを使用すると、同じプロセスをかなり安価に本番環境で使用できますが、この種の位置情報は非常に無駄であるため、リリースバイナリを実行することはできません。

DWARF情報よりも大幅に無駄になるのはなぜですか？ ファイル名は重複排除され、x64では全体が3ポインターのサイズになります。

@mitsuhikoだから基本的に、あなたは一般的な方向性に同意しますが、それの技術的な詳細には同意しませんか？

DWARF情報を一般的なRustAPIに公開するのはどのくらい簡単ですか？

@eddybは、DWARF情報がリリースバイナリに含まれておらず、個別のファイルに含まれているためです。 したがって、シンボルサーバーにデバッグファイルを配置し、削除されたバイナリをユーザーに送信できます。

@mitsuhikoああ、それは私が想定していたものとはまったく異なるアプローチです。 Rustは現在そのatm、AFAIKをサポートしていませんが、サポートする必要があることに同意します。

リリースバイナリをデバッグする目的でビルドシステムによって生成されたランダムな識別子と比較して、命令ポインタは実際にそれほど有用だと思いますか？

私の経験では、インラインデバッガーでは、明示的な自己/相互再帰と非常に大きな関数を除いて、スタックトレースの多くを回復するのに苦労しています。

はい、 try!は木枠に含まれています。 関数ポインタなどをライブラリコードに渡しても、関数にエラーがある場合でも、tryアプローチは機能します。 使用するクレートに内部エラーまたはバグがある場合、返されたErrの情報が役に立たない場合は、既にデバッグするためにそのソースコードが必要になることがあります。 スタックトレースは、コードにアクセスできる場合にのみ役立つため、クローズドソースライブラリ（コードを変更できない）は、何らかの方法でサポートを通過する必要があります。

単に両方のアプローチを有効にして、開発者にそれらに最適なものを決定させるのはどうですか？ 私は、TLSベースのアプローチに利点がないことを否定しません。

tryモデルは非常に簡単に実装でき、 ?をtryにデシュガーするだけで、 catchが入った場合は、追加の言語拡張のみが必要です（ハードコードされた動作内にその動作を追加します）とにかく? ）

@eddyb 「リリースバイナリをデバッグする目的でビルドシステムによって生成されたランダムな識別子と比較して、命令ポインタは実際に

これが、一般的なネイティブバイナリのデバッグの仕組みです。 私たち（Sentry）は、現時点ではほぼ完全にiOSサポートに使用しています。 クラッシュダンプを取得し、llvm-symbolizerを使用してアドレスを実際のシンボルに解決します。

@mitsuhikoすでにlibbacktrace埋め込んでいるので、それを使ってソースの場所へのコードポインタを解決できるので、私は完全に反対しているわけではありません。

@eddybええ。 パニックコードを見たところです。 それが実際にRustコードで使用できるAPIであるとしたら、それは素晴らしいことです。 これがさらにいくつかの場所で役立つことがわかります。

それについて-{Option、Result} :: unwrapに追加の型引数があり、デフォルトで関数が呼び出された場所に依存する型になり、それらからのパニックが発生するような型システムレベルのトリックについていくつか考えましたより便利な位置情報があります。

そういえば...

@glaebhoerlハァッ、多分それは実際に追求する価値がありますか？ 少なくともいくつかの不安定な実験として。

@eddybわからない。 おそらく最初にそれに関与したいくつかのGHCerとそれを議論する価値があります、私はこれについてただ通過するときに聞いて、ちょうど今リンクをグーグルで検索しました。 また、Rustには、GHCのように実際の暗黙的なパラメーターはありません。 デフォルトのタイプパラメータが代わりに機能するかどうかは興味深い質問です（おそらく私よりも多くのことを考えた質問です）。

考えてみてください。 rustcを特殊なケースに変換してErrを作成し、ペイロードを使用してfn(TypeId, *mut ())関数を呼び出してから返すようにすると便利です。 。 ペイロードに基づいてエラーをフィルタリングする、対象のエラーが検出された場合にデバッガーにトラップする、特定の種類のエラーのバックトレースをキャプチャするなどの基本的な作業から始めるには、これで十分です。

PR 33389は、 Carrier特性の実験的サポートを追加します。 これは元のRFCの一部ではなかったため、FCPに移行する前に特に綿密な調査と議論を行う必要があります（残りの?演算子についてはFCPとは別にする必要があります）。 詳細については、このディスカッションスレッドを参照してください。

?をOptionに拡張することに反対です。

RFCの表現は、 ?演算子がエラー/「例外」の伝播に関するものであるという事実についてかなり明確です。
Optionを使用してエラーを報告するのは間違ったツールです。 Noneを返すことは、成功したプログラムの通常のワークフローの一部ですが、 Errを返すことは、常にエラーを示します。

エラー処理の一部の領域を改善したい場合（スタックトレースを追加するなど）、 Option ?を実装すると、変更から?を除外する必要があります。 。

@tomakaディスカッションスレッドでディスカッションを続けることができあなたの異議をすでに要約しました）私は個人的にGHに関する長い議論がかなり扱いにくいと思います、そしてこの特定の点についての議論を他の将来の点や起こり得る質問から分離できることも素晴らしいでしょう。

@eddybはここだ、私は暗黙のコールスタックGHC機能のリリース版のドキュメント先に述べました。

しばらくの間、ここで更新はありません。 これを前進させるために働いている人はいますか？ OPの残りのタスクはまだ正確ですか？ ここで何かE-help-wantedはありますか？

意味のあるRust用のSentryクライアントを作成できるかどうか、先週末に遊んだ。 ほとんどのエラー処理は実際にはパニックではなく結果に基づいているため、これの有用性は、これを完全に放棄することを決定した時点に大幅に制限されていることに気付きました。

エラー報告システムを統合するための例として、crates.ioコードベースにアクセスしました。 これにより、このRFCに戻りました。結果が渡され、さまざまなスタックトレースに変換されるときに、何らかの方法で命令ポインターを記録できない限り、適切なエラーレポートを取得することは不可能だと思います。 私はすでに、これがローカルの複雑なロジック障害をデバッグするだけの大きな苦痛であることに気づきました。最近では、エラーの原因であると_考える_パニックを追加することに頼っています。

残念ながら、現在、結果の動作を大幅に変更せずにIPを記録する方法がわかりません。 他の誰かが以前にこのアイデアをいじったことがありますか？

これについては、@ rust-lang / langミーティングで話し合っていました。 思いついたいくつかのこと：

まず、 ?ができるだけ早く安定するのを見ることに明確な関心があります。 しかし、私たちのほとんどは、 ResultだけでなくOptionで?動作することも望んでいると思います（ただし、 boolではないようです。も提案されています）。 安定化に関する1つの懸念は、 Result以外のタイプの使用を許可するような特性を提供せずに安定化した場合、後で追加するための下位互換性がないことです。

たとえば、私自身、次のようなコードを定期的に記述しています。

let v: Vec<_> = try!(foo.iter().map(|x| x.to_result()).collect());

ここで、 try!を使用して、 collectがResult<Vec<_>, _>を返すことを期待していることを型推論に通知しています。 ?を使用した場合、この推論は将来失敗する可能性があります。

ただし、以前の議論では、あらゆる種類の「キャリア」特性のより細かい点を議論するために修正RFCが必要であると判断しました。 明らかに、このRFCはできるだけ早く作成する必要がありますが、その議論の?進行をブロックしたくないのです。

@nrcの実装を採用し、トレイトを不安定にしてResultといくつかのプライベートダミータイプに対してのみ実装した場合、 ?のみを作成しながら、推論を抑制する必要があると考えられました。 Result ?使用できます。

最後のポイント： Option値に?を使用する場合、関数の戻り値の型もOptionである必要があります（例ではありません）。 Result<T,()> ）。 多くの場合、宣言された戻り値の型から最終的にどの型が必要かを推測できるため、これが推論の制限に役立つことに注意するのは興味深いことです。

相互変換を望まない理由は、 xが整数型の場合でも、Cがif x許可する方法に似た、ルースロジックにつながる可能性が高いためです。 つまり、 Option<T>が値を示し、 Noneがその値のドメインの一部である場合（必要に応じて）、 Result<>は（通常）関数の失敗を表します。成功するためには、 Noneが関数のエラーが疑わしいと思われることを意味すると仮定します（そして一種の恣意的な慣習のように）。 しかし、その議論はRFCを待つことができると私は思います。

相互変換を望まない理由は、 xが整数型の場合でも、Cがif x許可する方法に似た、ルースロジックにつながる可能性が高いためです。 つまり、 Option<T>が値を示し、 Noneがその値の定義域の一部であり、 Result<>が（通常は）関数の失敗を表す場合成功するために、 Noneが関数がエラーになるはずであることを意味すると仮定すると、疑わしいように見えます（そして一種の恣意的な慣習のように）。 しかし、その議論はRFCを待つことができると私は思います。

私はこれに心から同意します。

手ぶれ補正に同意したもう1つの質問は、 From特性のimplが従うべき契約（またはErrアップキャストに使用することになった特性）を明確にすることでした。 ）。

@glaebhoerl

手ぶれ補正に同意したもう1つの質問は、From特性（またはErr-upcastingに使用する特性）が従う必要があるという契約を明確にすることでした。

確かに。 私の記憶をリフレッシュして、禁止されるべきだと思うことのいくつかの例から始めてもらえますか？ それとも、あなたが考えている法則だけですか？ 私はこのような「法律」に警戒していることを認めなければなりません。 一つには、彼らは実際には無視される傾向があります-人々は、意図された制限を超えていても、目的に合ったときに実際の行動を利用します。 つまり、もう1つの質問につながります。法律がある場合、それらを何かに使用するでしょうか。 最適化？ （しかし、私にはありそうもないようです。）

ちなみに、 catch式の状態はどうなっていますか？ それらは実装されていますか？

悲しいことにありません:(

2016年7月26日火曜日06:41:44 AM -0700に、AlexanderBulaevは次のように書いています。

ちなみに、 catch式の状態はどうなっていますか？ それらは実装されていますか？

---

スレッドを作成したため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/rust-lang/rust/issues/31436#issuecomment -235270663

おそらくあなたはそれを実装することを計画すべきですか？ 受け入れられているが実装されていないRFCほど気のめいることはありません...

cc＃35056

参考までに、 https：//github.com/rust-lang/rfcs/pull/1450 （列挙型バリアントのタイプ）は、 Carrier実装するいくつかの興味深い方法を開きます。 たとえば、次のようなものです。

trait Carrier {
    type Success: CarrierSuccess;
    type Error: CarrierError;
}

trait CarrierSuccess {
    type Value;
    fn into_value(self) -> Self::Value;
}

// (could really use some HKT...)
trait CarrierError<Equivalent: CarrierError> {
    fn convert_error(self) -> Equivalent;
}

impl<T, E> Carrier for Result<T, E>
{
    type Success = Result::Ok<T, E>;
    type Error = Result::Err<T, E>;
}

impl<T, E> CarrierSuccess for Result::Ok<T, E> {
    type Value = T;
    fn into_value(self) -> Self::Value {
        self.0
    }
}

impl<T, E1, E2> CarrierError<Result::Err<T, E2>> for Result::Err<T, E1>
    where E2: From<E1>,
{
    fn convert_error(self) -> Result::Err<T, E2> {
        Err(self.into())
    }
}

impl<T> Carrier for Option<T>
{
    type Success = Option::Some<T>;
    type Error = None;
}

impl<T> CarrierSuccess for Option::Some<T> {
    type Value = T;
    fn into_value(self) -> Self::Value {
        self.0
    }
}

impl<T> CarrierError<Option::None> for Option::None {
    fn convert_error(self) -> Option::None {
        self
    }
}

fn main() {
    let value = match might_be_err() {
        ok @ Carrier::Success => ok.into_value(),
        err @ Carrier::Error => return err.convert_error(),
    }
}

https://github.com/rust-lang/rust/pull/35056#issuecomment-240129923からいくつかの考えをクロスポストしたかっただけです。 そのPRは、ダミータイプのCarrier特性を導入します。 その意図は保護することでした。特に、型推論との相互作用を安定させることなく、 ?を安定させたかったのです。 特性とダミータイプのこの組み合わせは、安全に保守的であるように見えました。

次に、 Carrierについて説明するRFCを作成し、それに合わせて設計を変更して、全体的な形状に満足した場合にのみ安定化する（またはCarrier削除する）というアイデア

さて、もう少し投機的に言えば、 Carrier特性を採用する場合、キャリア間の相互変換を禁止したいと思います（この特性は基本的にResultとの間で変換する方法です） ?をOptionに適用すると、直感的に、fnがOption返す場合は問題ありません。 ?をResult<T,E>に適用する場合、fnがResult<U,F>返す場合は問題ありません。ここでE: Into<F> ; しかし、 ?をOptionし、fnがResult<..>返す場合、それは問題ありません。

とはいえ、この種のルールを今日の型システムで表現するのは難しいです。 最も明白な出発点は、HKTのようなものです（もちろん、実際にはありませんが、今は無視しましょう）。 しかし、それは明らかに完璧ではありません。 これを使用する場合、 ResultはCarrier実装できるため、 CarrierのSelfパラメーターの種類はtype -> type -> typeであると想定されます。 。 これにより、 Self<T,E> -> Self<U,F>ような表現が可能になります。 ただし、 type -> type種類のOptionは必ずしも適用されません（もちろん、これはすべて、採用したHKTシステムの種類によって異なりますが、私たちが採用したとは思いません。 「一般的なタイプのラムダ」までずっと行きます）。 さらに極端なのは、 boolようなタイプかもしれません（boolにCarrierを実装したくないのですが、新しいタイプにCarrierを実装したいと思う人もいるかもしれません。 'd bool）。

私が考えたのは、 ?の型付け規則自体が特別である可能性があるということです。たとえば、 ? Foo<..>は_some_の名目型Carrier特性と一致しますが、囲んでいるfnの戻り値の型もFoo<..>ます。 したがって、基本的にFoo 、新しい型パラメーターを使用して?が適用されているタイプも、囲んでいるfnのタイプもわからない場合、新しい種類の特性義務を追加せずにこの制約を適用できないことです。 それはまた、かなりアドホックです。 :)しかし、それはうまくいくでしょう。

私が持っていたもう1つの考えは、 Carrier特性を再考するかもしれないということExpr: Carrier<Return>ここで、 Exprは?が適用されるタイプであり、 Returnは環境のタイプです。 たとえば、おそらく次のようになります。

trait Carrier<Target> {
    type Ok;
    fn is_ok(&self) -> bool; // if true, represents the "ok-like" variant
    fn unwrap_into_ok(self) -> Self::Ok; // may panic if not ok
    fn unwrap_into_error(self) -> Target; // may panic if not error
}

次に、 expr?次のように脱糖します。

let val = expr;
if Carrier::is_ok(&val) {
    val.unwrap_into_ok()
} else {
    return val.unwrap_into_error();
}

ここでの主な違いは、 Targetは_error_タイプではなく、新しいResultタイプになることです。 したがって、たとえば、次のimplを追加できます。

impl<T,U,E,F> Carrier<Result<U,F>> for Result<T,E>
    where E: Into<F>
{
    type Ok = T;
    fn is_ok(&self) -> bool { self.is_ok() }
    fn unwrap_into_ok(self) -> Self::Ok { self.unwrap() }
    fn unwrap_into_error(self) -> { Err(F::from(self.unwrap_err())) }
}

そして、次のように追加します。

impl<T> Carrier<Option<T>> for Option<T> {
    type Ok = T;
    fn is_ok(&self) -> bool { self.is_some() }
    fn unwrap_into_ok(self) -> Self::Ok { self.unwrap() }
    fn unwrap_into_error(self) -> { debug_assert!(self.is_none()); None }
}

そして最後に、次のようにブール値を実装できます。

struct MyBool(bool);
impl<T> Carrier<MyBool> for MyBool {
    type Ok = ();
    fn is_ok(&self) -> bool { self.0 }
    fn unwrap_into_ok(self) -> Self::Ok { debug_assert!(self.0); () }
    fn unwrap_into_error(self) -> { debug_assert!(!self.0); self }
}

現在、このバージョンはより柔軟です。 たとえば、次のようにResultを追加することで、 impl Option値間の相互変換をResult変換できるようにすることができます。

impl<T> Carrier<Result<T,()>> for Option<T> { ... }

しかしもちろん、そうする必要はありません（そしてそうする必要もありません）。

@Stebalien

参考までに、rust-lang / rfcs＃1450（列挙型バリアントのタイプ）は、Carrierを実装するいくつかの興味深い方法を開きます

書いたばかりのアイデアを書いているときに、列挙型バリアントの型を用意し、それが物事にどのように影響するかを考えていました。

?を使用するコードを記述していることに気付いたのは、「throw」キーワードがないのは少し面倒だということです。特に、 Err(foo)?を記述した場合、コンパイラーはそうしません。 tこれが返されることを_知っている_ので、 return Err(foo)と書く必要があります。 それは大丈夫ですが、自分で書かないとinto()コンバージョンは得られません。

これは、次のような場合に発生します。

let value = if something_or_other() { foo } else { return Err(bar) };

ああ、もう1つ追加する必要があります。 implが型推論に影響を与えることを許可するという事実は、fnがResult<..>返すコンテキストでは、 foo.iter().map().collect()?意味します。これは、型注釈が必要ないことがわかっている場合は、 fnの戻り値の型はResult 、1つのimplのみが（少なくともローカルで）適用される可能性があります。

ああ、そして、私のCarrier特性の少し良いバージョンはおそらく次のようになります：

trait Carrier<Target> {
    type Ok;
    fn into_carrier(self) -> Result<Self::Ok, Target>;
}

次のように実装します。

impl<T,U,E,F> Carrier<Result<U,F>> for Result<T,E>
    where E: Into<F>
{
    type Ok = T;
    fn into_carrier(self) -> Result<T, Result<U,F>> {
        match self { Ok(v) => Ok(v), Err(e) => Err(e.into()) }
    }
}

そして、 expr?は次のようなコードを生成します。

match Carrier::into_carrier(expr) {
    Ok(v) => v,
    Err(e) => return e,
}

もちろん、これの欠点（または利点...）は、 Into変換がimplにプッシュされることです。つまり、意味のあるときに人々がそれらを使用しない可能性があります。 ただし、（特定のタイプの）望ましくない場合は、それらを無効にできることも意味します。

@nikomatsakis IMO、特性はIntoCarrierある必要があり、 IntoCarrier::into_carrierは、このような結果を再利用する代わりに、 Carrier （新しい列挙型）を返す必要があります。 あれは：

enum Carrier<C, R> {
    Continue(C),
    Return(R),
}
trait IntoCarrier<Return> {
    type Continue;
    fn into_carrier(self) -> Carrier<Self::Continue, Return>;
}

@Stebalien確かに、大丈夫そうです。

langチームミーティングでの議論（および?オペレーターのみのFCPの可能性）に指名します。 今後数日以内に、ある種の一時的なキャリア特性をFCPに着陸させる必要があると思います。

キャリアの特性について話し合うために、rust-lang / rfcs＃1718を開きました。

あなたがたを聞いて、あなたがたを聞いてください！ ?演算子は、具体的には最終コメント期間に入っています。 この議論は、おおよそ8月18日に始まったこのリリースサイクルの間続きます。 ?演算子を安定させる傾向があります。

キャリア特性に関しては、一時的なバージョンが＃35777に上陸しました。これにより、型推論との望ましくない相互作用を防ぐことで、どちらの方法でも自由に決定できるようになります。

@ rust-lang / langメンバーは、同意を示すために名前を確認してください。 懸念や反対意見をコメントに残してください。 その他、コメントを残してください。 ありがとう！

• [x] @nikomatsakis
• [x] @nrc
• [x] @aturon
• [x] @eddyb
• [] @pnkfelix （休暇中）

tokioベースのライブラリがand_thenを多用することになるのではないかと思います。 これは、 foo().?bar()をfoo().and_then(move |v| v.bar())省略形にして、結果と先物が同じ表記を使用できるようにするための1つの引数になります。

明確にするために、このFCPはquestion_mark機能キャッチではありません、正しいですか？ この号のタイトルは、この1つの号でこれらの機能の両方を追跡することを意味します。

@seanmonstar後者はまだ実装されていないので、そうです。 おそらく、FCPが受け入れられた場合、これはcatchを追跡するように変更されます。

明確にするために、このFCPはquestion_mark機能に関するものであり、キャッチではありません。 この号のタイトルは、この1つの号でこれらの機能の両方を追跡することを意味します。

はい、 question_mark機能だけです。

https://github.com/rust-lang/rfcs/issues/1718#issuecomment-241764523でフォローアップし? "バインド現在の継続"に一般化することができますが、 map_err(From::from)の一部?少しだけバインドよりも、それを作ります：/。 結果にFromインスタンスをすべて追加すると、セマンティクスはv? => from(v.bind(current-continuation))なる可能性があります。

この内部スレッドでは、 ?の相対的なメリットについて多くの議論がありました。

https://internals.rust-lang.org/t/the-operator-will-be-harmful-to-rust/3882/

今、詳細な要約をする時間がありません。 私の記憶では、コメントは?がエラーに注意を引くのに十分に見えるかどうかという問題に焦点を合わせていますが、おそらく議論の他の側面を見落としています。 他の誰かが要約する時間があれば、それは素晴らしいことです！

私は以前にコメントしたことがなく、これは遅すぎるかもしれませんが、@ haulethが@をリンクしたディスカッションで指摘したように、 ?演算子が非表示の戻りステートメントとして使用されている場合も、混乱を招きます。ニコマタキス。

try!使用すると、マクロでそれを実行できるため、どこかにリターンがある可能性があることは明らか?を非表示のreturnとして使用すると、関数から値を返す方法は3つあります。

• 暗黙のリターン
• 明示的なリターン
• ?

@CryZeが言ったように、私はこれが好きです：

このように、それは誰にでもなじみがあり、エラーを最後までパイプダウンして処理でき、暗黙のリターンはありません。 したがって、大まかに次のようになります。

a = try！（x？.y？.z）;

これは、コードをより簡潔にするのに役立ち、リターンを隠しません。 また、 coffeescriptなどの他の言語でもおなじみです。

?関数レベルではなく式レベルで解決すると、先物にどのような影響がありますか？ 他のすべてのユースケースでは、私にとっては問題ないようです。

@CryZeが言ったように、私はこれが好きです：

このように、それは誰にでもなじみがあり、エラーを最後までパイプダウンして処理でき、暗黙のリターンはありません。 したがって、大まかに次のようになります。

a = try！（x？.y？.z）;

私はこれを仮定しました。 完璧な解決策になると思います。

try！を使用すると、マクロでそれを実行できるため、どこかにリターンがある可能性があることは明らかでした。

Rustでマクロがどのように機能するかを知っているので、それは明らかです。 ?が安定し、広く普及し、Rustのすべてのイントロで説明されると、これはまったく同じになります。

@conradkleinespel

関数から値を返す方法は3つあります。

• 暗黙のリターン

Rustには「暗黙のリターン」はなく、値に評価される式があります。 これは重要な違いです。

if foo {
    5
}

7

Rustに「暗黙のリターン」がある場合、このコードはコンパイルされます。 しかし、そうではありません。 return 5が必要です。

一度はまったく同じになるのはどれですか？ は安定していて広く普及しており、Rustのすべてのイントロで説明されています。

それがどのように見えるかの例については、 https：//github.com/rust-lang/book/pull/134

try！を使用すると、マクロでそれを実行できるため、どこかにリターンがある可能性があることは明らかでした。
Rustでマクロがどのように機能するかを知っているので、それは明らかです。 一度はまったく同じになるのはどれですか？ は安定していて広く普及しており、Rustのすべてのイントロで説明されています。

私が知っているどの言語でも、「マクロ」は「ここでドラゴンになってください」を意味し、何かが起こる可能性があることを意味します。 つまり、「Rust」の部分を除いて、「マクロの動作に精通しているから」と言い換えます。

@hauleth

a = try！（x？.y？.z）;

私はこれを仮定しました。 完璧な解決策になると思います。

私は強く反対します。 try!でのみ機能し、外部では機能しない魔法のシンボルが表示されます。

@hauleth

a = try！（x？.y？.z）;
私はこれを仮定しました。 完璧な解決策になると思います。
私は強く反対します。 あなたは試してみてのみ機能する魔法のシンボルを手に入れるでしょう！ 外ではありません。

?がtry!のみ機能するはずだとは言っていません。 私が言っていたのは、 ?は、データをストリームにプッシュし、発生するとすぐにエラーを返すパイプ演算子のように機能するはずだということです。 その場合、 try!は必要ありませんが、現在使用されているのと同じコンテキストで使用できます。

@steveklabnik Rustは暗黙的に返される言語だと思います。あなたの例では、 5は暗黙的に返されません

fn test() -> i32 {
    5
}

ここでは、 5が暗黙的に返されますね。 return 5;とは対照的に、例では必要になります。 これにより、値を返す2つの異なる方法が可能になります。 Rustについては少し混乱します。 3分の1を追加しても、IMOは役に立ちません。

そうではない。 これは、式、具体的には関数本体の結果です。 「暗黙のリターン」とは、どこからでも暗黙的に戻ることができることを意味しますが、そうではありません。 上記の私のコードサンプルのように、これを「暗黙のリターン」と呼ぶ他の式ベースの言語はありません。

@steveklabnikわかりました、これを説明するために時間を割いてくれてありがとう：+1：

大丈夫だよー！ 私はあなたがどこから来ているのかを完全に見ることができます、それは人々がしばしば間違った方法で使う2つの異なるものです。 「暗黙のリターン」とは、ソース内のどこでも;オフのままにして、リターンすることができると人々が想定しているのを見たことがあります。

@hauleth ？ その場合、演算子はand_thenのシンタックスシュガーになります。 そうすれば、より多くの場合にそれを使用することができ、返品を見逃すのは難しいことではありません。 これは、他のすべての言語が行うことでもありますか？ オペレーター。 さびの？ 現在の実装の演算子は、他のすべての言語が行うことの正反対です。 また、and_thenは機能的なアプローチであり、明確な制御フローがあるため、とにかく推奨されます。 だから作るだけ？ and_thenの構文糖衣構文を使用して、現在の試行を維持します。 明示的に「アンラップして返す」ために、戻り値をより見やすくし、？ 演算子がより柔軟になります（パターンマッチングなどのリターンのない場合に使用できるため）。

丁度。

ŁukaszNiemier
[email protected]

Wiadomośćnapisana przezクリストファーSERR [email protected] O godz dniu 2016年2月9日、ワット 21:05：

@hauleth https://github.com/hauleth ？ その場合、演算子はand_thenのシンタックスシュガーになります。 そうすれば、より多くの場合にそれを使用することができ、返品を見逃すのは難しいことではありません。 これは、他のすべての言語が行うことでもありますか？ オペレーター。 さびの？ 現在の実装の演算子は、他のすべての言語が行うことの正反対です。 また、and_thenは機能的なアプローチであり、明確な制御フローがあるため、とにかく推奨されます。 だから作るだけ？ and_thenの構文糖衣構文を使用して、現在の試行を維持します。 明示的に「アンラップして返す」ために、戻り値をより見やすくし、？ 演算子がより柔軟になります（パターンマッチングなどのリターンのない場合に使用できるため）。

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

そして、Rustリポジトリのプルリクエストで作業するとき、私は実際に？を使用するコードで作業する必要がありました。 演算子であり、実際、それは私にとって読みやすさを本当に傷つけます。 非常に隠されていて（精神的には、脳内でフィルターで除去されるのは単なるノイズであるため）、私はそれをよく見落としていました。 そして、それはかなり怖いです。

私たちは、「暗黙の復帰」と呼ん@steveklabnikので、我々はありません唯一のもの。

@haulethええと、Rubyの私の何年にもわたって、暗黙のリターンと呼ばれる人のことは聞いたことがありません。 私はまだそれについて考えるのは間違った方法だと主張します。

私はいくつかのプロジェクトで?ましたが、主に接尾辞の位置にあるため、 try!よりも優先しました。 一般的には、「本物の」錆コードはかなり入りResultで「モナド」 mainし、時折葉ノード以外では、それを離れることはありません。 そして、そのようなコードは常にエラーを伝播することが期待されています。 ほとんどの場合、どの式がエラーを生成しているかは関係ありません。それらはすべてスタックに送り返されるだけであり、コードのメインロジックを読んでいるときにそれを見たくありません。

?に関する私の主な懸念は、メソッドマクロが存在する場合、同じ利点（接尾辞の位置）を取得できることです。 おそらく現在の定式化を安定させることによって、エラー処理の将来の表現力を制限しているという他の懸念があります-現在のResult変換は、Rustでのエラー処理を私が望むほど人間工学的にするのに十分ではありません。 Rustエラー処理では、修正が難しいと思われるいくつかの設計ミスがすでに発生しており、これにより、さらに深く掘り下げられる可能性があります。 具体的な証拠はありませんが。

私はこれを何度も書いたことがありますが、 ?とキャリア特性の可能性が大好きです。 1つのプロジェクトを?完全に使用するように変換したところ、 try!と複雑すぎる多くのことが可能になりました（特にチェーンに関して）。 私はまた、他のいくつかのプロジェクトを見て、それらが?どのように機能するかを確認しましたが、全体としては問題は発生していません。

そのため、 Carrierというより適切な名前の特性に基づいて、 ?安定化に大きな+1を与えます。これは、他の議論で取り上げた他のいくつかのケースも理想的にカバーしています。

私の主な関心事は？ メソッドマクロが存在する場合は、メソッドマクロでも同じ利点（接尾辞の位置）を得ることができるということです。

多分これにはRFCが必要ですか？ ほとんどの人は？の機能を気に入っているようですが、？は好きではありません。 自体。

多分これにはRFCが必要ですか？ ほとんどの人は？の機能を気に入っているようですが、？は好きではありません。 自体。

これについて多くの議論があるRFCがあります。 また、あなたがその「ほとんどの人」をどこから得ているのかわかりません。 もちろん、この号の参加者からのものである場合、安定化はチームのデフォルトのアクションであるため、反対する人が増えるでしょう。
?は、RFCがマージされる前に大いに議論されており、サポーターとして、安定化が議論されるときに同じことをしなければならないのはちょっと疲れます。

とにかく、ここに@mitsuhikoの感情の+1を入れます。

これについては多くの議論があるRFCがあります。 また、あなたがその「ほとんどの人」をどこから得ているのかわかりません。 もちろん、この号の参加者からのものである場合、安定化はすでにチームのデフォルトのアクションであるため、より多くの人々が反対しているのを目にするでしょう。

申し訳ありませんが、私のコメントは短すぎました。 func1().try!().func2().try!()など、ある種の「メソッドマクロ」のRFCを作成することについて言及していました（私が知る限り、これは現在不可能です）。

個人的に私は好きですか？ 演算子ですが、 @ brsonと同じ懸念事項を共有しています。この機能を安定させる前に、代替案を検討することをお@nikomatsakisがリンクした内部スレッドを繰り返されたとしても、この機能については確かにいくつかの論争があります。 ただし、実行可能な代替手段がない場合は、安定化が最も理にかなっています。

機能を完全に実装せずに安定化するのは時期尚早のようです。この場合、catch {..}式です。

私は以前にこの機能について懸念を表明しましたが、それでも悪い考えだと思います。 接尾辞の条件付き戻り演算子を持つことは、他のプログラミング言語とは異なり、Rustをすでに拡張された複雑さの予算を超えて押し進めていると思います。

@mcpherrinm代わりに、他の言語では、エラー処理の呼び出しごとに巻き戻しパスが隠されています。 operator()を「条件付き戻り演算子」と呼びますか？

複雑さの予算に関しては、少なくともあなたが不満を言っている部分は、構文的にtry!とは異なります。
try!反対する議論は、 ?だけが読みやすくなる重いコードですか？
もしそうなら、「エラー伝播の自動化をまったく行わない」以外の深刻な代替案があるかどうかに同意します。

妥協案の提案： https ：

受け入れられるチャンスはないかもしれませんが、とにかくやってみます。

@keeperofdakeysの「メソッドマクロ」に関するアイデアが好き?構文を受け入れるべきではないと思います-読みやすさ。 ?自体は何も言いません。 代わりに、「メソッドマクロ」を使用して?の動作を一般化する機能が必要です。

a.some_macro!(b);
// could be syntax sugar for
some_macro!(a, b); 

a.try!();
// could be syntax sugar for
try!(a); 

このように、動作が何であるかが明確になり、簡単に連鎖できるようになります。

result.try!()ようなメソッドマクロは、言語の人間工学に対するより一般的な改善のようであり、新しい?演算子よりもアドホックではないと感じます。

@brson

おそらく現在の定式化を安定させることによって、エラー処理の将来の表現力を制限しているという他の懸念があります-現在の結果変換は、Rustでのエラー処理を私が望むほど人間工学的にするのに十分ではありません

これは興味深い点です。 これに焦点を当てた時間を費やす価値があるでしょう（おそらくあなたと私は少しチャットすることができます）。 ここでもっとうまくやれることに同意します。 Carrier特性の提案された設計（https://github.com/rust-lang/rfcs/issues/1718を参照）は、物事をより柔軟にするため、特に特殊化と組み合わせると、ここで役立つ可能性があります。

メソッドマクロが言語の優れた拡張になるとは本当に思えません。

macro_rules!マクロは現在、解放関数と同様の方法で宣言されており、新しいインポートシステムが採用されるとさらに類似するようになります。 つまり、それらはトップレベルのアイテムのように宣言され、トップレベルのアイテムのように呼び出され、まもなくトップレベルのアイテムのようにインポートされるということです。

これはメソッドの仕組みではありません。 メソッドには次のプロパティがあります。

1. モジュールスコープで宣言することはできませんが、 implブロック内で宣言する必要があります。
2. 直接インポートされるのではなく、 implブロックが関連付けられているタイプ/特性でインポートされます。
3. このスコープ内の単一の明確なシンボルであることに基づいてディスパッチされるのではなく、レシーバータイプに基づいてディスパッチされます。

マクロはタイプチェックの前に展開されるため、私が知る限り、メソッド構文を使用するマクロにはこれらのプロパティのいずれも当てはまりません。 もちろん、メソッド構文を使用するマクロを「無料」マクロと同じ方法でディスパッチおよびインポートすることもできますが、その違いにより、非常に紛らわしい機能になると思います。

これらの理由から、「メソッドマクロ」がいつか現れるかもしれないという信念で?を遅らせるのは良い選択ではないと思います。

さらに、いくつかのコンストラクトが非常に広く使用されており、マクロから砂糖に昇格する必要があるほど重要なラインがあると思います。 forループは良い例です。 ?動作は、Rustのエラー処理ストーリーに不可欠であり、マクロではなくファーストクラスのシュガーであることが適切だと思います。

@ hauleth 、 @ CryZe

?はand_then演算子であるべきだという提案に答えるために、これは拡張関数を多用しているため、Kotlin（私はcoffeescriptに精通していません）のような言語でうまく機能しますが、さびでとても簡単です。 基本的に、 and_thenほとんどの用途はmaybe_i.and_then(|i| i.foo())ではなく、 maybe_i.and_then(|i| Foo::foo(i)) 。前者はmaybe_i?.foo()として表現できますが、後者は表現できません。 Foo::foo(maybe_i?, maybe_j?)がmaybe_i.and_then(|i| maybe_j.and_then(|j| Foo::foo(i, j))) Foo::foo(maybe_i?, maybe_j?)変わると言うこともできますが、これは、エラーと評価される最初の?をヒットすると、さびが早期に戻ると言うよりもさらに混乱します。 ただし、これは間違いなくより強力です。

@Stebalien受け入れられたRFCでは、 catch { Foo::foo(maybe_i?, maybe_j?) }はあなたが望むことをします。

@eddyb良い点。 「しかし、これは間違いなくもっと強力だろう」を省くことができると思います。 それは、暗黙的なキャッチ/明示的な試行と明示的なキャッチ/暗黙的な試行に帰着します。

let x: i32 = try Foo::foo(a?.b?.c()?));
let y: Result<i32, _> = Foo::foo(a?.b?.c()?);

対：

let x: i32 = Foo::foo(a?.b?.c()?);
let y: Result<i32, _> = catch  Foo::foo(a?.b?.c()?);

（モジュロ構文）

@Stebalien別の例： Fooを関数barに渡したい場合、あなたの提案で次のことを行う必要があります。

bar(Foo::foo(a?.b?.c()?)?)

これはあなたが考えていることですか？ 余分な注意? 、それなしbarなるだろうResultの代わりにFoo 。

@eddybおそらく。 注：私は実際にこれを提案していません！ ?をパイプ演算子として使用することは、 Foo::foo(bar?)ケースを処理する方法がなければ、さびでは特に有用ではないと私は主張しています。

私はメソッドマクロのアイデアが嫌いであり、私がこれ以上強く反対する言語機能を考えることができないことに注意してください。 それらはコンパイラーのフェーズを曖昧にし、言語に本当に非常に根本的な変更を加えない限り、それらが存在して驚くことのない振る舞いをする方法はありません。 また、それらは賢明に解析するのが難しく、ほぼ確実に下位互換性がありません。

@Stebalien 、パイプ演算子Foo::foo(bar?) ?としてFoo::foo(try!(bar))およびbar(Foo::foo(a?.b?.c()?)?) （ Foo::foo : fn(Result<_, _>) -> Result<_, _>仮定）： bar(try!(Foo::foo(a?.b?.c()?))) 。

@hauleth私のポイントは、Foo::foo(bar?)?がbar?.foo()?よりも_はるかに_一般的であるということ?がこのケースをサポートする必要があります（または他の機能を導入する必要があります）。 私はそうする方法を仮定し、その方法が少なくとも厄介であることを示していました。 ?要点は、 try!(foo(try!(bar(try!(baz()))))) （括弧の2倍！）を書かないようにすることです。 通常、これをtry!(baz()?.bar()?.foo())として書き直すことはできません。

しかし、あなたはいつでもすることができます：

try!(baz().and_then(bar).and_then(foo))

ŁukaszNiemier
[email protected]

Wiadomośćnapisana przezスティーブン・アレン[email protected] O godz dniu 2016年5月9日、ワット 15:39：

@haulethhttps ：//github.com/hauleth私のポイントはFoo :: foo（bar？）？ bar？.foo（）よりもはるかに一般的ですか？ さびで。 したがって、役に立つために、？ このケースをサポートする必要があります（または他の機能を導入する必要があります）。 私はそうする方法を仮定し、その方法が少なくとも厄介であることを示していました。 ？の全体のポイント try！（foo（try！（bar（try！（baz（））））））（2x括弧！）;の記述を回避できるようにすることです。 通常、これをtry！（baz（）?. bar（）?. foo（））として書き直すことはできません。

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

少し関連したメモとして、？-機能は主にビルダーによって使用されているようです。したがって、結果をラップするビルダーを構築する簡単な方法を提供することで、？-機能の必要性を回避できる可能性があります。。 ここで何か提案しましたが、もう少し手間がかかるかもしれません。

https://github.com/colin-kiegel/rust-derive-builder/issues/25

メソッドマクロのアイデア@nrcと@withoutboatsについて考えてくれてありがとう、それらが機能しないいくつかの具体的な理由を聞くのは良いことです。

@nielsle ?が「主に」ビルダーによって使用されていると言うのは正確ではないと思います。 ビルダーは、軽量の接尾辞演算子の利点が実際に発揮されると思う例ですが、すべてのコンテキストでtry!よりも?方が好きです。

@nielsle先物に関して、私はもともと同様の理由で心配していました。 しかし、それについて考えた後、私はasync / awaitがその文脈での?必要性に取って代わると思います。 それらは実際にはかなり直交しています。 (await future)?.bar()ようなことを行うことができます。

（キーワードawait代わりにサフィックス演算子を使用すると、親が不要になる場合があります。または、慎重に調整された優先順位で十分な場合もあります。）

安定する前に、いくつかのドキュメントを作成してほしいと思います。 参考文献を調べましたが、言及が見つかりませんでした。 この機能をどこに文書化する必要がありますか？

チャンスがありますので、彼らは安定化されることはありませんならば、それは時間の無駄になります、私は一般的に文書化することを回避する不安定な機能を@steveklabnik知っ@cbreeden。 以前にドキュメント作成の安定化をブロックしたことがあるかどうかはわかりません。

@solsonそうです、これはおそらくそれを持ち出す場所ではありませんでした-または少なくとも安定化の質問に関連するべきではありません。 機能の安定化を決定できる状況を想像していたと思いますが、安定したrustcにリリースする前にドキュメントも必要です。 ドキュメントと機能の安定化およびリリースの統合に関連するRFCがあるため、そのプロセスが安定するのを待つだけです（もちろん、最初に適切なドキュメントがないわけではありません）。

このRFCの重要な部分は、 try!ように機能する式の右側にあるものを用意することだと思います。これにより、「try」の順次/連鎖使用法の読み取りが読みやすくなり、「catch」が使用できるようになります。 。 もともと私は構文として?を使用する100％のサポーター?を使用しているいくつかの（クリーンな！）コードに出くわしました。これにより、簡単な例から外で?は非常に見落とされがちです。 これで、「新しい試行」の構文として?を使用することは大きな間違いである可能性があると私は信じています。

したがって、構文として?または他の記号を使用することについてのフィードバックを得るために、（フォーラムでの通知とともに）終了する前に_投票を行う_ことをお勧めします。 。 より長い関数での使用例を使用するのが最適です。 ?名前を変更して、他に何も変更しないことをお勧めすることだけを考えていることに注意してください。 世論調査では、 ?! （または?? ）のように過去にポップアップした可能性のある他の名前、または「use？vs。use more thanoncharacter」のような名前をリストできます。

ところで。 ?ないことも、他の言語のオプションタイプと同じ構文であるため、それを嫌う人々を満足させる可能性があります。 そして、それをrustOptionタイプのオプション構文にしたい人。 （これは私が共有する懸念ではありませんが）。

さらに、このような世論調査では、通常はRFCプロセスに参加していない人々に連絡できると思います。 通常、これは必要ないかもしれませんが、 try! => ?は、Rustコードを書いたり読んだりする人にとって非常に大きな変更です。

PS：
私が我慢する要旨をさまざまなバリエーションで上に気に入っ機能付き（「？」、「？」、「??」）以上があった場合、私は知りませんて。 また、 ?名前を?!に変更するためのRFCがあり、この議論にリダイレクトされました。

申し訳ありませんが、すでに長い進行中の議論を再開する可能性について：smiley_cat:。

（ expr???はあいまいになるため、オプションに?を導入する場合は、 ??は不適切であることに注意してください）

?は非常に見落とされがちです

ここで何について話し合っていますか？ 完全に強調表示されていないコード？ 定期的に強調表示されたコードブラウジング？
または、関数で?を積極的に探していますか？

エディターで1つの?を選択すると、ファイル内の他の?が明るい黄色の背景で強調表示され、検索機能も機能するため、最後の?が表示されません。私にとって困難をもたらすものとして。

他の場合については、 ??または?!で終わるよりも、強調表示することでこれを解決したいと思います。

@dathinab .try！（）か何かがもっと良いと思いますが、それはマクロにUFCSを必要とします。

let namespace = namespace_opt.ok_or(Error::NoEntry).try!();

そうすれば見逃すことはありませんが、 .unwrap()よりも入力が簡単ではないにしても同じくらい簡単です。

@eddyb ：通常のハイライトされたコードについてです（例：github）。 たとえば、コードベースを読み取る場合。 私の観点からすると、 ?を簡単に見落とさないように強力な強調表示が必要な場合は、一種の間違いを感じます。これにより、別のリターンパス（/ catch to catch）が導入され、変数のタイプがResult<T>から変更される可能性があります。 T

@CryZe ：私はあなたに同意しますが、近い将来これを得ることができるとは思いません。 そして、 .try!()より少し短いものを持っていることもそれほど悪くはありません。

@CryZe私もその構文が好きですが、 @ withoutboatsは、メソッドマクロが言語を傷つける可能性があるいくつかの確かな理由について言及しました。
一方、メソッドマクロが表示された場合、それらが?うまく機能するとは思えません。

私は本質的にこの印章に2つの文字を使用することに反対していませんが、例を調べたところ、 ?が表示されなくなった変更は見つかりませんでした。

ええ、同じです。 通常の言語とプログラミング言語の両方で、一般に記号は構造化に多く使用されるため、これは何らかのキーワードである必要があると思います。

@CryZe ：たぶん?tryようなものは一種のキーワードでしょう。 しかし、正直なところ、私はそれが好きではありません（ ?try ）。

@eddyb

検索機能も動作します

?を検索すると誤検知が発生しますが、バージョンが長いと誤検知が発生する可能性があります。

探している ？ 誤検知が発生しますが、長いバージョンでは発生しない可能性があります。

構文ハイライターがこれを内部的に処理することを期待しています（誤検知を回避します）。 実際のところ、彼らはフリンジ（行番号の隣）に何らかの形の「リターンかもしれない」マーカーを挿入することさえできます。

例えば、

うわー、それは間違いなく大いに役立ちます。 しかし、あなたは本当にあなたを確認する必要があります
エディターを適切に構成します。これは常に行うことはできません（
たとえば、GitHubで）。

2016-09-15 23:52 GMT + 02：00スティーブンアレン[email protected] ：

例えば、
[画像：画面-2016-09-15-175131]
https://cloud.githubusercontent.com/assets/310393/18568833/1deed796-7b6d-11e6-99af-75f0d7ddd778.png

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

@CryZeGitHubがオープンソースのシンタックスハイライトを使用していると確信しています。 パッチを当てることができます:-)。

一般に、Rustプロジェクトでは、可視性に関する懸念のバランスをとるために、Rustの構文ハイライターが?で視認性の高いスタイルを使用することを推奨することをお勧めします。

?がここでできる最善の選択だと思います。そして、ミリではかなり頻繁に使用しています。

元の動機に戻って、 try!(...)は邪魔になり、エラーの流れを無視してハッピーパスを読むのが難しくなります。 これは、従来の言語の目に見えない例外と比較して欠点です。 ?をより複雑なキーワードに拡張すると、同じ欠点があります。

一方、 ?を使用すると、エラーの流れを気にしない場合は無視して、バックグラウンドにフェードインさせることができます。 そして、エラーの流れを本当に気にかけているときでも、 ?なく表示されます。 ?明るく強調することは私にとってさえ必要ではありませんが、それが他の人々を助けるなら、それは素晴らしいことです。 これは、目に見えない例外とtry!両方を改善したものです。

?!ような些細な大きさの印章に切り替えても、私はまったく役に立ちませんが、エラー処理コードの読み取りと書き込みがわずかに悪化します。

心のこもった最後のコメント期間（および以前の内部スレッド）をみんなに感謝します。 これまでで多いRFCについて話していることを考えると、安定化に関する議論も非常に活発であることに驚かされることはありません。

最初に追いかけましょう。@ rust-lang / langチームは、 Resultタイプの値に適用されたときに、 ?演算子を安定させることを決定しました。 catch機能が安定していないことに注意してください（実際、まだ実装されていません）。 同様に、 ?をOptionようなタイプに拡張する手段である、いわゆる「キャリア特性」は、 RFC前の議論段階にあります。 ただし、現在の実装では、後でCarrierトレイトを追加

8月22日にFCPが開始されてから行われた議論を要約するために少し時間をかけたいと思います。 これらのテーマの多くは、元のRFCスレッドでも発生しました。 スレッドを読むことに興味がある場合は、そのスレッドのFCPコメントと要約コメントが会話を詳細にカバーしようとします。 場合によっては、このスレッドの対応するコメントよりも詳細な場合は、元のスレッドのコメントにリンクします。

?演算子のスコープは、現在の関数ではなく、現在の式である必要があります。

エラーが発生すると、今日のtry!マクロは、そのエラーを呼び出し元の関数に無条件に伝播します（つまり、エラーとともにreturnを実行します）。 現在設計されているように、 ?演算子はこの前例に従いますが、ユーザーがより限定されたスコープを指定できるようにするcatchキーワードをサポートすることを目的としています。 これは、たとえば、 x.and_then(|b| foo(b))をcatch { foo(x?) }と書くことができることを意味します。対照的に、最近のいくつかの言語では、 ?演算子を使用して、 and_then類似したものを意味しています。

最終的に、 catchが実装されると、これはデフォルトの問題になります。 また、Rustの?は、デフォルトの「関数のブレークアウト」（カスタマイズオプション付き）がより適切であると考える理由がいくつかあります。

• try!マクロは、非常に便利なデフォルトとして何度も証明されています。 ?は、 try!代わりになることを目的としているため、同じように動作するのは当然です。
• Rustの?は、主に結果の伝播に使用されます。これは、例外に類似しています。 すべての例外システムは、デフォルトで現在の関数から呼び出し元にエラーを伝播します（Swiftのように、そうするためにキーワードも必要とするシステムでも）。
  
  
  
  • 対照的に、SwiftやGroovyなどの?は、null値またはオプションタイプと関係があります。
  
  
  • キャリア特性を採用した場合、Rustの?演算子は、上記のシナリオで（特に、 catchと組み合わせて）引き続き使用できますが、_main_ユースケースではありません。
  
  
• 今日のRustでのand_then多くの使用は、メソッド表記を使用しても機能しません。 いくつかの予測される将来の使用（futuresなど）は、いずれの場合もasync-await変換に含まれる可能性ます

?は、見つけるのが難しいため、制御フローを覆い隠します。

よくある懸念は、 ?演算子が見落としやすいことです。 これは明らかにバランスをとる行為です。 軽量なオペレータを持つことは、それが簡単に「幸せな道」あなたがしたいときに注力することができます-しかし、それはエラーが（暗黙の制御フローを導入例外とは対照的に）起こることができる場所のいくつかの兆候を持っていることが重要です。 また、作るのは簡単です? （例えば、構文強調を通じて発見しやすくする1 、 2 ）。

なぜマクロをメソッド化しないのですか？

?の大きな利点の1つは、修正後の位置で使用できることですが、
foo.try!ような「メソッドマクロ」からも同様のメリットを得ることができます。 確かに、メソッドマクロは、特にメソッドのように動作させたい場合（たとえば、レシーバーのタイプに基づいてディスパッチされ、字句スコープを使用しない場合）、それ自体が非常foo.try!ようなメソッドマクロを使用すると、 foo?よりもかなり重い重量感があります（前のポイントを参照）。

Fromはどのような契約を提供する必要がありますか？

元のRFCの議論では、[ From 「契約」があるべきかどうか]（（https://github.com/rust-lang/rust/issues/31436#issuecomment）の質問を延期することにしました。 -180558025）。langチームの一般的なコンセンサスは、 ?演算子をFrom特性を呼び出すものと見なす必要があり、 From特性の実装は自然に何でもできるということです。 From特性の役割は、とにかくここではかなり制限されていることに注意してください。これは、ある種類のエラーから別の種類のエラーに変換するために使用されます（ただし、常にResultコンテキストで使用されます）。

ただし、 「キャリア」特性に関する議論は進行中であり、そのシナリオでは強力な規則をます。 特に、キャリア特性は、タイプの「成功」と「失敗」を構成するもの、およびある種類の値（たとえば、 Option ）を別の種類の値（たとえば、 Result ）。 多くの人が、「エラーのような」タイプ間の任意の相互変換をサポートしたくないと主張し?はOptionをResultに変換できないはずです）。 明らかに、エンドユーザーは自分のタイプに応じてCarrierトレイトを実装できるため、これは最終的にはガイドラインですが、重要なものだと思います。

ポートトライ！ 使用するには？

これを逆方向に互換性を持って行うことはできないと思います。 try!の実装はそのままにしておく必要があります。 try!を非推奨にする必要がありますか？

@nrcなぜ下位互換性がないのですか？

@withoutboats try!(x)は(x : Result<_, _>)?あり、_望んでいた場合はおそらくそのように実装できますが、一般的にx?はCarrierをサポートするものなら何でも推測できます特性（将来）、1つの例はiter.collect()?で、これはtry! Resultなりますが、実際にはOptionます。

それは理にかなっている。 stdにimplを追加すると、推論があいまいになる可能性があることを受け入れたと思いました。 ここでもそれを受け入れてみませんか？

いずれにせよ、 try!は非推奨にすべきだと思います。

？ はコンテキストのようなビルダーパターンでより便利ですが、tryはコンテキストのようなネストされたメソッドでより便利です。 それが何を意味するにせよ、それは非推奨にされるべきではないと思います。

@ est31推論を除いて、今はまったく同じことをしています。 正確に何を意味するのかわかりませんが、 ?は通常、厳密にクリーンです（ここでもモジュロ推論）。 例を挙げていただけますか？

@eddyb foo()?.bar()?.baz()はtry!(try!(foo()).bar()).baz()よりも優れており、 try!(bar(try!(foo())))はbar(foo()?)?よりも優れています

どちらの場合も?方が読みやすいと思います。 不要な括弧の乱雑さを減らします。

これはいつ安定して着陸しますか？

@ofekこれはすべてのためのものであり、まだ完了していないので、言うのは難しいです。 https://github.com/rust-lang/rust/pull/36995は、基本的な?構文を安定させました。これは、1.14で安定しているはずです。

？を追加することを忘れないでください安定した参照への演算子： https ：//doc.rust-lang.org/nightly/reference.html#unary -operator-expressions

また、 @ blussは、この本も古くなっていると指摘しました： https ： //doc.rust-lang.org/nightly/book/syntax-index.html

@tomaka

私は延長に反対ですか？ オプションへ。

エラーの目的で使用する必要はありません。 たとえば、 getを取得し、それを何らかの関数でマッピングするためのラッパーメソッドを作成した場合、 Noneケースを伝播できるようにしたいと思います。

？ エラーのためだけのものとして売り込まれました。 このような一般的な伝播のより一般的な表記は、目標ではありませんでした。

2016年10月29日、11：08 -0400、tickiで[email protected] 、書きました：

@tomaka （https://github.com/tomaka）

私は延長に反対ですか？ オプションへ。

エラーの目的で使用する必要はありません。 たとえば、getを取得し、それを何らかの関数でマッピングするためのラッパーメソッドが必要な場合は、Noneの場合を伝播できるようにしたいと思います。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub（https://github.com/rust-lang/rust/issues/31436#issuecomment-257096575）で表示するか、スレッドをミュートします（https://github.com/notifications/unsubscribe -auth / AABsipGIpTF1-7enk-z_5JRYYtl46FLPks5q42DCgaJpZM4HUm_-）。

これ（= ?自体）は安定した機能になりました！ （錆1.13より）

2つのドキュメントの問題：

• [x]ブック＃37750のエラー処理の章を更新
• [x]現在の状況に合わせてCarrierトレイトドキュメントを更新＃37751

catchもCarrierトレイトもまだ適切に実装されておらず、裸の?機能だけであることに注意してください。

Carrierが存在し、 ?を使用するとエラーメッセージがそれを参照するため、キャリアの問題が拒否されるのではなく修正された方がよいでしょう。 ドキュメントはOption用に実装されていることを参照しているため、ドキュメントも更新する必要があります。 （これは誤りです）。

35946は、エラーメッセージからCarrier記述を削除する必要があります。 少なくともCarrierドキュメントからOption言及を削除する必要があるように思えます。

Carrierトレイトとの相互作用のため、この問題にT-libsを追加します

@cramertjが遭遇した質問： https ： //internals.rust-lang.org/t/grammatical-ambiguity-around-catch-blocks/4807

こんにちは; ＃31954では、エラータイプのアップキャストはFromを使用して行われます（現在のヘッドでも同様です）が、 RFC 243では変換にIntoを使用する必要があると明確に述べています。

代わりにFromが使用された理由はありますか？ いくつかの一般的なエラータイプ（つまり、 io::Error 、または外部クレート内の他の何か）にアップキャストしようとすると、ローカルエラータイプにFromを実装できません。

（RFC 243の作成者としてのFWIWは、 FromとIntoどちらが望ましいかについてはあまり考えていませんでした。正しい選択をしたかどうかは、まったくわかりませんでした。質問は、RFCに書かれていることではなく、メリット（この時点では下位互換性が含まれている可能性があります）に基づいて決定する必要があります。）

悲しいことに、回帰があります。 無（非自明な）場合From<...>インスタンスエラータイプに対して実施され、コンパイラが使用する場合、それを推測することができない特定の場合にタイプ、推定することができるInto （のセットFromインスタンスは現在のクレートによって制限されており、クレートのコンパイル中はIntoインスタンスのフルセットは不明です）。

https://play.rust-lang.org/?gist=6d3ee9f93c8b40094a80d3481b12dd00（src / librustc / util / ppaux.rs＃L81のfmt::Errorに関連する現実の問題から「簡略化」）を参照してください。

?の記述に関して古いものに取って代わる新しいRFCがあります：rust-lang / rfcs / pull / 1859

私はcatchブロックを持っていることに-1ですが、それらはすでにクロージャーではるかに簡潔です。

クロージャは、フロー制御ステートメントに干渉します。 （ break 、 continue 、 return ）

https://github.com/rust-lang/rfcs/pull/1859がマージされ、この問題を追跡の問題として再利用していると主張しているので、 catchを再評価することを提案したいと思いcatch部分。

私は、我々は完全にそれを取り除くことを提案していないんだけど、への熱意catchそれがためだったとして偉大なようではなかった?それはまだ光の中で理にかなっていることを確認し、私はそれの価値が作ると思います?で出現し、 Tryに照らして出現すると予想されるイディオムの一部。

私はまだキャッチしたいと思っています。 今日の初めに、キャッチが安定していれば回避できた方法でコードをゆがめなければなりませんでした。

この機能は、構文do catchで毎晩実装されていますね。

@withoutboatsはい、 catch { ... }は構造体リテラル（ struct catch { }; catch { } ）と競合するため、現在はdo catchです。
。
@archshift @SimonSapinが上で指摘したように、クロージャはbreak 、 continue 、およびreturn干渉します。

@bstrie最近はcatchかなり頻繁に欲しいと思います。 リファクタリング中に多く発生します。

構文としてdo catchを要求することを計画していることに気づきませんでした。 実際の破損のリスクが非常に低いように思われる場合（どちらも構造体の命名ガイドラインに違反し、コンストラクターをステートメントの最初の式にする必要があります（これは戻り位置以外ではまれです））、おそらくrustfmtを活用して問題のある識別子をcatch_書き換えますか？ それがそうするためにRust2.0を必要とするなら、まあ、私はいつもRust2.0がとにかく些細な破壊的な変更だけを含むべきであると言う人でした...：P

@bstrie do catch長期的に要求することは絶対に望んでいません。 今のところその構文を使用することになった議論はここにあります： https ：

素晴らしい、コンテキストに感謝します。

catchが安定していることを望み、そうではないことを学ばなければならなかったので、ここに来ました。そうです、もちろん、 ?が安定しているので、 catchもあるといいでしょう

私はこれの残りの部分でどこまで到達したかを見たかったし、docatchの議論を見ました。

私はこのような場合に役立つおそらくばかげた考えを検討してきました：オプションでキーワードの前に@または他の印章を付けて、すべての新しいキーワードに印章のみを使用させる。 コルーチンの議論でも同様の問題がありました。 そこで解決策としてこれに入ったかどうかは思い出せませんが、そうかもしれませんが、これは今後も続く可能性があります。

FWIW、C＃は実際には反対のことをサポートしています：識別子としてキーワードを使用するための@ 。 これはRazorでよく見られ、 new { <strong i="6">@class</strong> = "errorbox" }などを渡してHTMLノードにプロパティを設定します。

@scottmcm
それは面白い。 私はそれについて知りませんでした。 しかし、Rustの場合、互換性があるため、逆の方向に進む必要があります。

しかし、彼らの側の素晴らしいアイデア。 .netエコシステムには多くの言語があり、すべてが異なるキーワードを持ち、すべてが相互に呼び出すことができます。

キーワードの将来のもう1つの可能性は、ある種の安定した#[feature]ように、属性の後ろにキーワードを配置することです。

この問題は、長期的にはより一般的な解決策が必要になると思います。

@camlornこのスレッドは、特にRustの「エポック」に関するアーロンのアイデアに興味があるかもしれません： https ： //internals.rust-lang.org/t/pre-rfc-stable-features-for-breaking-changes/5002

ここの問題の説明からhttps://github.com/rust-lang/rust/issues/42327をリンクする必要があると思います。 （また、RFCテキストを更新して、ここではなくそこにリンクする必要があるかもしれません。）

（編集：コメントを投稿しましたが、誰が購読しているかどうかはわかりません！）

@camlornただし、「rustfmtはしばらくの間、些細な書き直しを行った後、キーワードになります」というパスを開く可能性があります。 AKAは、安定性保証のエスケープハッチを利用して、「両方で機能するように記述された可能性のある追加の注釈があれば壊れません」。 また、推論の変更に関するUFCSと同様に、架空の「完全に精巧な形式で保存」モデルを使用すると、古い木枠を機能させ続けることができます。

catchブロックの構文がdo { … }だけだったとしても、 ?{ … }だったとしてもかまいません。

doは、すでにキーワードであるという優れた特性があります。 Haskellのようなdo表記を呼び出すという疑わしい（視点によっては）プロパティがありますが、これは過去の使用を停止することはなく、これはユースケースにやや近いものです。

見た目も似ていますが、提案されたjavascriptとは異なる動作を

その提案は、すでに裸のブロックを式として使用しているRustにはあまり関係がありません。

どちらも同じように見えますが、まったく異なることをするため、混乱の可能性を指摘していました。

Haskellのようなdo-notationを呼び出すという疑わしい（あなたの視点に応じて）特性があります

@rpjohnst ResultとOptionはモナドであるため、少なくとも概念的には似ています。 また、将来的にすべてのモナドをサポートするように拡張するには、上位互換性が必要です。

そうです、過去には、モナドに概念的に似ているものにdoを追加すると、完全にサポートされていないと、人々が悲しくなるという反対意見がありました。

同時に、完全なdo-notationと上位互換性を持たせることはできますが、完全なdo-notationを追加するべきではありません。 if / while / for / loopまたはbreak / continue /のような制御構造では構成できません。 return 。これは、 catch （またはこの場合はdo ）ブロック内およびブロックcatchブロックの内容を一連のネストされたクロージャに詰め込むと、突然すべてのブレークを制御するためです。）

したがって、最終的に、このdo欠点は、実際にはdo表記ではなく、do表記になるための適切なパスもないdo表記のように見えることです。 個人的には、Rustはとにかくdo表記を取得しないので、これでまったく問題ありませんが、それは混乱です。

@ nikomatsakis 、＃42526がマージされ、追跡リストで完了としてマークできます:)

catchキーワードをコンテキストに合わせて作成することはできますが、 struct catchがスコープ内にある場合は無効にして、非推奨の警告を発行しますか？

これがどれほど適切かはわかりませんが、 returnを使用するときに現在可能であるエラー値ではなく、okを中止したい場合があるという点で、おそらくこれを解決する必要がある問題に遭遇しました。 _outer_を介して_inner_エラーを中止します。 関数sayがOption<Result<_,_>>を返すときのように、これはsayイテレータから非常に一般的です。

特に、現在私が豊富に使用しているプロジェクトにマクロがあります。

macro-rules! option_try {
    ( $expr:expr ) => {
        match $expr {
            Ok(x)  => x,
            Err(e) => return Some(Err(e.into())),
        }
    }
}

Iterator::next実装内で呼び出された関数は、失敗するとすぐにSome(Err(e))で中止する必要があることは非常に一般的です。 このマクロは通常の関数本体の内部で機能しますが、catchはreturnカテゴリ別に取得せず、特別な?構文のみを取得するため、catchブロックの内部では機能しません。

最終的にラベル付きリターンはcatchブロックのアイデア全体を冗長にしますが、そうではありませんか？

＃41414が完了したようです。 誰かがOPを更新できますか？

更新：RFC rust-lang / rfcs＃2388がマージされたため、 catch { .. }はtry { .. }置き換えられます。
このコメントのすぐ上にある追跡の問題を参照してください。

これはEdition2015にとって何を意味しますか、 do catch { .. }構文はまだ安定化への道を進んでいますか、それともこれは削除され、Edition 2018+ではtry { .. }を介してのみサポートされますか？

@ Nemo157後者。

現在の提案には2つのステートメントtry ... catch ...がありますか？ もしそうなら、私はセマンティクスを取得しません。

とにかく、この提案が脱糖だけに関するものであれば、私はそれでかっこいいです。 つまり、 catchブロックは、 ?演算子が終了する場所を変更するだけですか？

上部の投稿ですべてのチェックボックスがオンになっているので、いつ先に進みますか？ それでも未解決の問題がある場合は、新しいチェックボックスを追加する必要があります。

おそらく、記録されていない未解決の質問がたくさん残っています。
たとえば、ok-wrappingの動作は、langチーム内で解決されません。また、 Tryの設計は確定されません。 この問題は、その有用性を超えている可能性が高いため、おそらくこの問題をさらにいくつかの対象を絞った問題に分割する必要があります。

うーん...これらの質問が記録されていないのは気になります。

@ mark-im明確にするために、私は彼らがどこかにいたと思います。 しかし、1つの場所ではありません。 さまざまなRFCや問題などで少し散らばっているATMなので、適切な場所に記録する必要があります。

バッキングトレイトのデザインはhttps://github.com/rust-lang/rust/issues/42327で追跡されてい

したがって、ここにはtry{}が残っていると思います。私が知っている唯一の不一致は、RFCで解決され、上記の問題の1つで再確認されたものです。 ただし、明確な追跡の問題があるとよいでしょう。

まだ実行する必要があることがわかっている保留中の実装タスクのチェックボックスを追加します...

@scottmcm @joshtriplettがOKラッピング（ try RFCに記載）について懸念を持っていたことを知っています。個人的には、 try { .. }の初期安定化でbreakを制限したいと思います。 loop { try { break } }などはできません。

@Centril

loop { try { break } }ができないように

現在、非ループブロックでbreakを使用することはできません。これは正しいことです。 breakはループでのみ使用する必要があります。 tryブロックを早期に残すための標準的な方法は、 Err(e)?を書き込むことです。 そしてそれは初期の葉が常に「異常な」制御経路にあることを強制します。

したがって、私の提案は、あなたが示したコードは許可されるべきであり、 try残すだけでなく、 loopを壊すはずです。

直接の利点は、 breakが表示されたときに、ループから抜け出そうとしていることを知っていることです。いつでもcontinue置き換えることができます。 また、 loop内でtryブロックを使用していて、ループを終了する場合に、ブレークポイントにラベルを付ける必要がなくなります。

@Centrilそれらを育ててくれてありがとう。

breakに関してtryはbreakを気にせず、包含ループに渡されると言っても問題ありません。 breakがtryと相互作用することをまったく望んでいません。

Okラッピングについては、はい、 try安定させる前に対処したいと思います。

@centrilはい、承知しています。 しかし、それはそれは問題を提起再再だことを覚えておくことが重要です。 RFCはそれを持つことを決定し、それなしで実装されましたが、その後、元の意図が_再び_取られ、実装はRFCに従うように変更されました。 したがって、私の大きな質問は、特にこれがRFC + IRLOで議論された中で最も騒々しいトピックの1つであることを考えると、重要な事実が変更されたかどうかです。

@scottmcmもちろん、ご存知のように、私はOk -wrapping;）を保持することに同意し、問題が解決したと見なされるべきであることに同意します。

これについてコメントしたかったのですが、これが正しいかどうかはわかりません。

基本的に、私が抱えている状況はGUIフレームワークでのコールバックです- OptionまたはResultを返す代わりに、 UpdateScreenを返す必要があります。更新する必要があるかどうか。 多くの場合、ログを記録する必要はまったくなく（すべてのマイナーエラーにログオンするのは実際的ではありません）、エラーが発生したときにUpdateScreen::DontRedraw返すだけです。 ただし、現在の?演算子では、これを常に記述する必要があります。

let thing = match fs::read(path) {
    Ok(o) => o,
    Err(_) => return UpdateScreen::DontRedraw,
};

Try演算子を使用してResult::ErrからUpdateScreen::DontRedraw変換できないため、これは非常に面倒になります。ハッシュマップで単純なルックアップが失敗することがよくあります（これはエラーではありません）。 ）-1回のコールバックで?演算子を5〜10回使用することがよくあります。 上記は書くのが非常に冗長なので、私の現在の解決策は、このようにimpl From<Result<T>> for UpdateScreen 、次に次のようにコールバックで内部関数を使用することです。

fn callback(data: &mut State) -> UpdateScreen {
     fn callback_inner(data: &mut State) -> Option<()> {
         let file_contents = fs::read_to_string(data.path).ok()?;
         data.loaded_file = Some(file_contents);
         Some(())
     }

    callback_inner(data).into()
}

コールバックは関数ポインターとして使用されるため、 -> impl Into<UpdateScreen>使用できません（何らかの理由で、 impl返すことは現在関数ポインターでは許可されていません）。 したがって、 Try演算子を使用する唯一の方法は、内部関数のトリックを実行することです。 私が単にこのようなことをすることができればそれは素晴らしいでしょう：

impl<T> Try<Result<T>> for UpdateScreen {
    fn try(original: Result<T>) -> Try<T, UpdateScreen> {
        match original {
             Ok(o) => Try::DontReturn(o),
             Err(_) => Try::Return(UpdateScreen::DontRedraw),
        }
    }
}

fn callback(data: &mut State) -> UpdateScreen {
     // On any Result::Err, convert to an UpdateScreeen::DontRedraw and return
     let file_contents = fs::read_to_string(data.path)?;
     data.loaded_file = Some(file_contents);
     UpdateScreen::Redraw
}

現在の提案でこれが可能かどうかはわかりませんが、検討のためにユースケースを追加したかっただけです。 カスタムのTry演算子がこのようなものをサポートできれば素晴らしいと思います。

編集：
私が間違えました。

この投稿は無視してください

これは型推論でうまく機能するでしょうか、単純な場合でも失敗します。

fn test_try(a: u32, b: u32) {
    let div = if b != 0 {
        Some(a / b)
    } else {
        None
    };

    let x // : Option<_> // why is this type annotation necessary
    = try { div? + 1 };

    println!("{:?}", x);
}

これがtryブロックの代わりにクロージャを使用するように書き直された場合（そしてその過程で緩い自動ラッピング）、次のようになります。

fn test_closure(a: u32, b: u32) {
    let div = if b != 0 {
        Some(a / b)
    } else {
        None
    };

    let x =  (|| (div? + 1).into())();

    println!("{:?}", x);
}

これは型アノテーションを必要としませんが、結果をラップする必要があります。

遊び場

@KrishnaSannasiクロージャベースの例でも型推論の失敗があります（ playground ）。 Intoは出力を制約せず、後で使用する場所では使用しないためです。

これは主に、 tryブロックではなくTry特性の問題のようです。これは、 Intoと同様に、入力から出力に型情報を伝播しないためです。出力タイプは、後で使用することによって判別できる必要があります。 https://github.com/rust-lang/rust/issues/42327に特性についての議論がたくさんありますが、私はそれを読んでいないので、そこにある提案のいずれかがこの問題を修正できるかどうかはわかりません。

@ Nemo157

はい、コードを使用するために最後の最後の変更を行いましたが、テストはしませんでした。 私の悪い。

トライブロックの安定化からどのくらい離れていますか？ それは私が毎晩から必要とする唯一の機能です：D

@Arignir

これができれば、安定できると思います。

try {} catch（または他の次のID）をブロックして、将来のためにデザインスペースを開いたままにし、代わりに、マッチでやりたいことを行う方法を人々に示します。

将来のためにデザインスペースを開いたままにする可能性を残しながら、現在この機能を許可する中間設計はありませんか（したがって、最終的にはcatchブロック）？

私が作ったPRはとにかくそのボックスをチェックする必要があります、CC @nikomatsakis

私は昨日これを初めて使用しようとしました、そして私はこれに少し驚いていました：

#![feature(try_blocks)]
fn main() -> Result<(), ()> {
    let x: () = try {
        Err(())?
    }?;
    Ok(x)
}

のためにコンパイルされません

error[E0284]: type annotations required: cannot resolve `<_ as std::ops::Try>::Ok == _`

むしろ、私はしなければなりませんでした

#![feature(try_blocks)]
fn main() -> Result<(), ()> {
    let x: Result<(), ()> = try {
        Err(())?
    };
    let x = x?;
    Ok(x)
}

代わりに。

これは最初は混乱していたので、エラーメッセージを変更するか、 --explain言及する価値がありますか？

最初の例の疑問符を少し下に移動すると

#![feature(try_blocks)]
fn main() -> Result<(), ()> {
    let x: () = try {
        Err(())?
    };
    Ok(x?)
}

より良いエラーメッセージが表示されます。 Rustは、一般的であるため、 try { ... }を解決するタイプを決定できないため、エラーが発生します。 このタイプを解決できないため、 <_ as Try>::Okタイプが何であるかを知ることができません。そのため、エラーが発生しました。 （ので、 ?オペレータはアンラップTryタイプとバック与えるTry::Okタイプ）。 Rustは、それ自体ではTry::Okタイプでは機能しません。それは、 Tryトレイトと、そのトレイトを実装するタイプによって解決する必要があります。 （これは、タイプチェックが機能する現在の方法の制限です）

この機能のすべてが実装されていますよね？ もしそうなら、安定する前にこれに座っていることをどのくらい見たいですか？

これが欲しいかどうかはまだ未解決の問題だと思いました。 特に、ここで例外の言語を使用するかどうかについていくつかの議論がありました（try、catch）。

個人的には、Rustには例外のような印象を与えようとすることに強く反対しています。 特にcatchという単語を使用することは悪い考えだと思います。例外のある言語から来た人は誰でも、これがほどけると思い込んでいるからです。 教えるのは混乱し、苦痛だと思います。

特に、ここで例外の言語を使用するかどうかについていくつかの議論がありました（try、catch）。

https://github.com/rust-lang/rfcs/pull/2388は、名前としてtryが受け入れられるかどうかを決定的に解決したと思います。 これは未解決の質問ではありません。 しかし、 Try特性とOkラッピングの定義はそうであるようです。

Ok -wrappingは、元のRFCですでに決定されており、実装中に削除され、最後に後で再度追加されました。 それがどのように未解決の質問であるかわかりません。

@rpjohnstそれは、Joshが元のRFCの決定に同意しなかったためです... :)それは私にとって解決された問題https://github.com/rust-lang/rust/issues/31436#issuecomment -427096703、 https://github.com/rust-lang/rust/issues/31436#issuecomment -427252202、およびhttps：//でgithub.com/rust-lang/rust/issues/31436#issuecomment-437129491 。 とにかく...私のコメントのポイントは、「例外の言語」としてのtryは解決された問題であるということでした。

うわー、これはいつ起こったの？ 私が覚えている最後のことは、内部に関する議論でした。 Ok-ラッピングにも非常に反対です:(

Eww。 これが起こったとは信じられません。 Ok -wrappingは非常にひどいです（関数内のすべての戻り値の型は関数の戻り値の型でなければならないという非常に賢明な直感を壊します）。 そうですね、間違いなく@ mark-imを使用します。 Joshの意見の不一致は、これを未解決の問題として維持し、それについてさらに議論するのに十分ですか？ チームメンバー以外のことを意味するのではなく、これと戦うために彼を喜んでサポートしたいと思います。

Ok -RFC 243で受け入れられているラッピング（これがいつ発生したのか疑問に思っていた?演算子を定義したもの）は、関数の戻り式の型について何も変更しません。 これはRFC243がそれを定義した方法です： https ：

このRFCは、 ?演算子を「スコープ」するのに役立つ式フォームcatch {..}も導入しています。 catch演算子は、関連するブロックを実行します。 例外がスローされない場合、結果はOk(v)ここで、 vはブロックの値です。 それ以外の場合、例外がスローされると、結果はErr(e)ます。

catch { foo()? }は基本的にfoo()と同等であることに注意してください。

つまり、タイプTブロックを受け取り、それを無条件にラップして、タイプResult<T, _>値を生成します。 ブロック内のreturnステートメントはまったく影響を受けません。 ブロックが関数のテール式である場合、関数はResult<T, _>返す必要があります。

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=88379a1607d952d4eae1d06394b50959のように、この方法で毎晩実装されてい多くの議論の後に行われ、リンクされています：rust-lang / rust＃41414（これはこの問題の上部にもリンクされています）。

2019年5月28日5時48分27秒PM PDTで、アレクサンダーRegueiroの[email protected]は書きました：

Eww。 これが起こったとは信じられません。 Okラッピングはとてもひどいです（それは
すべてが式を返すという非常に賢明な直感を破ります
関数は関数の戻り値の型である必要があります）。 そうそう、間違いなく
これについては@ mark-imを使用します。 Joshの意見の不一致は、これを維持するのに十分ですか
未解決の問題、そしてそれについてのより多くの議論を得ますか？ 私は喜んで彼にサポートを貸します
これと戦うことにおいて、それが非チームメンバーとして何かを意味するということではありません。

ありがとうございました。 私は自分のためだけにこれに反対しているだけではありません。 私はまた、私が見た多くの人々が私と同じ立場を表明していることを代表しています。

@joshtriplett @ mark-im @alexreg

Okラッピングが非常に不快だと思う理由を説明したり、以前に説明した場所へのリンクを提供したりできますか？ 探しに行ったのですが、ざっと見ると何も見えませんでした。 私はこれに馬を持っていません（私はすべてのボックスがチェックされ、1か月間議論がなかったので、これについてコメントしただけです）が、このスズメバチの巣を蹴ったので、議論をよりよく理解したいと思います。

2019年5月28日火曜日03:40:47 PM -0700に、ラッセルジョンストンは次のように書いています。

Ok -wrappingは、元のRFCですでに決定されており、実装中に削除され、最後に後で再度追加されました。 それがどのように未解決の質問であるかわかりません。

自分の質問に部分的に答えたと思います。 誰もがそうは思わない
元のRFCの議論に関与したのは同じページでした。 tryは
絶対に多くの人が望んでいたものですが、コンセンサスはあり
OKラッピング用。

2019年5月28日火曜日03:44:46 PM -0700、MazdakFarrokhzadは次のように書いています。

とにかく...私のコメントのポイントは、「例外の言語」としてのtryは解決された問題であるということでした。

明確にするために、私は「例外」のメタファーが魅力的だとは思いません。
そして、try-fnやOk-wrappingのようなものでの試みの多くは
例外のようなメカニズムを持つ言語を偽造しようとします。
しかし、 try自体は、 ?以外の場所でキャッチする手段として
関数境界は、制御フロー構造として意味があります。

2019年5月28日火曜日、午後11時37分33秒-0700に、ガブリエル・スミスは次のように書いています。

Okラッピングがとても不快だと思う理由を説明できますか

いくつかの理由の1つとして：

2019年5月28日火曜日05:48:27 PM -0700に、AlexanderRegueiroは次のように書いています。

これは、関数内のすべての戻り値の型が関数の戻り値の型である必要があるという非常に賢明な直感を破ります。

これは、人々がタイプ指向の推論に使用するさまざまなアプローチを破ります
関数とコード構造について。

私は確かにここで私自身の考えを持っていますが、今このトピックを再開しないでください。 構文について500以上の投稿で論争があったので、しばらくの間地雷を避けたいと思います。

それについて話し合っているlangチームでこれがブロックされている場合は、「catchブロックが結果値を「ラップ」するかどうかを解決する（＃41414）」チェックボックスを再度オフにして（おそらくlangチームでブロックされているというコメントを付けて）、この追跡の問題はステータスを知っていますか？

申し訳ありませんが、私は何も再開しようとはしていません。追跡の問題で決定されたとマークされたものと、それがいつ+どのように発生したかを言い直してください。

@rpjohnst情報をありがとう！

@yodaldevoidJoshは私の考えをほぼ要約しました。

私は（関数のタイプに影響を与えるのではなく）ブロックに限定されたok-wrappingに少し反対していませんが、それでも悪い前例を設定していると思います：Joshが言ったように「例外のメタファーは魅力的ではありません」

@joshtriplettは、基本的に私の見解も要約しています。問題は、「例外」メタファーの適合性（おそらくパニック+ catch_unwindははるかに類似しています）とタイプベースの推論です。 私はスコーピングと制御フローのメカニズムとしてtryブロックでも大丈夫ですが、もっと急進的なポイントではありません。

さて、十分に公平です、ここで全体の議論をしないでください...多分提案されたようにチェックボックスをオフにして、このスレッドで言及された理論的根拠のいくつかを使用して、それをlang-teamの議論に戻しますか？ 安定化が急がない限り、それは合理的に聞こえると思います。

型注釈の構文は合意されていますか？ 私はいくつかのtry { foo()?; bar()?; }.with_context(|_| failure::err_msg("foon' n' barn'")?;を望んでいましたが、それはコンパイルにリモートでさえ興味がありません： error[E0282]: type annotations needed 。

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4e60d44a8f960cf03307a809e1a3b5f2

私はしばらく前に、コメントを通じて少しを読んで（とgithubの上の300件のコメントを再びロードがあまりにも退屈である）が、私はリコールを行うこと（すべてではない）、ほとんどの周りの議論についての例のTry::Okラップ使用Ok 。 OptionがTryも実装していることを考えると、それが議論のどちら側にあるかというチームの立場にどのように影響するかを知りたいと思います。

Rustを使用するたびに、「男、ここでtryブロックを使用できればいいのに」と思い続けますが、その約30％は、tryをOption使用したいからです（私はScalaで以前、 for構文を使用してモナドに一般的に適用していましたが、ここではtryと非常によく似ています。

ちょうど今日、私はjsonクレートを使用していましたが、オプションを返すas_*メソッドが公開されています。

2つの構文を使用すると、私の例は次のようになります。

match s {
  "^=" => |a, b| try { a.as_str()?.starts_with(b.as_str()?) }.unwrap_or(false),
  "$=" => |a, b| try { Some(a.as_str()?.ends_with(b.as_str()?)) }.unwrap_or(false),
  // original
  "$=" => |a, b| {
    a.as_str()
      .and_then(|a| b.as_str().map(|b| (a, b)))
      .map(|(a, b)| a.starts_with(b))
      .unwrap_or(false)
    },
}

文脈上、戻り値の型がOptionかResultはかなり明確であり、さらに、（コードの理解に関する限り）実際には問題ではないと思います。 透過的に、その意味は明確です。「これら2つのことが有効かどうかを確認し、それらに対して操作を実行する必要があります。」 tryように、この関数がより大きなコンテキストに埋め込まれていると考えると、理解が失われるとは思わないので、これらのいずれかを選択する必要がある場合は、最初のものを使用します。常に。

このスレッドを最初に見始めたときは、明示したほうがいいと思ったので、 Okラッピングに反対しましたが、それ以来、「私が欲しい」と言った時間に注意を払い始めました。ここでtryブロックを使用できます」と私はOkラッピングが良いという結論に達しました。

私は当初、最後のステートメントがTryを実装する型を返す関数である場合、 Ok折り返しではない方がよいと考えていましたが、構文の違いは次のようになります。

try {
  fallible_fn()
}

try {
  fallible_fn()?
}

この場合も、 fallible_fnがTry返す関数であることが明確になるため、 Okラッピングの方が優れていると思います。したがって、実際にはより明示的です。

反対派がこれについてどう思っているか知りたいのですが、このスレッドでは他の多くの人を見ることができないので、@ joshtriplettです。

編集：私はこれを人間工学/読解の観点からのみ見ていました。 推論が簡単になるなど、実装の面で一方が他方よりも技術的なメリットがあるかどうかはわかりません。

ネストされたOption解析にも、 tryを試してみたかったのです。

#![feature(try_blocks)]

struct Config {
    log: Option<LogConfig>,
}

struct LogConfig {
    level: Option<String>,
}

fn example(config: &Config) {
    let x: &str = try { config.log?.level? }.unwrap_or("foo");
}

これは失敗します

error[E0282]: type annotations needed
  --> src/lib.rs:12:19
   |
12 |     let x: &str = try { config.log?.level? }.unwrap_or("foo");
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
   |
   = note: type must be known at this point

私が得た最も近いものは

fn example(config: &Config) {
    let x: Option<&str> = try { &**config.log.as_ref()?.level.as_ref()? };
    let x = x.unwrap_or("foo");
}

as_refは非常に残念です。 Option::derefがここで役立つことは知っていますが、十分ではありません。 これは、どういうわけか人間工学（または関連するアイデア）と一致する必要があるように感じます。

複数の行も残念です。

tryは、整数リテラルのようにResult推論フォールバックを使用できますか？ @shepmasterの最初の試みでResult<&str, NoneError>推測できますか？ 残りの問題は何ですか？おそらく、変換する?の一般的なエラータイプを見つけますか？ （私はこれについてどこかで議論を逃したことがありますか？）

@shepmaster型推論に同意します。 おかしなことに、私はあなたの正確なコードをややナイーブなtry_実装で試しましたが、正常に動作します： https ：

    let x = try_! { config.log?.level? }.unwrap_or("foo".to_owned());
    assert_eq!(x, "debug");

正常に動作します。

ややナイーブなtry_実装

はい、しかし、あなたのマクロ呼び出しは返しますString 、ない&str 、必要な所有権を。 周囲のコードは表示されませんが、 Config所有権がないため、これは失敗します。

fn example(config: &Config) {
    let x = try_! { config.log?.level? }.unwrap_or_else(|| String::from("foo"));
}

error[E0507]: cannot move out of captured variable in an `Fn` closure
  --> src/lib.rs:20:21
   |
19 | fn example(config: &Config) {
   |            ------ captured outer variable
20 |     let x = try_! { config.log?.level? }.unwrap_or_else(|| String::from("foo"));
   |                     ^^^^^^^^^^ cannot move out of captured variable in an `Fn` closure

また、無条件にString割り当てます。 この非効率性を回避するために、この例ではunwrap_or_elseを使用しました。

この機能がasync/awaitブロックの前に安定しなかったのは残念です。 IMOを持っていればもっと一貫していたでしょう

let fut = async try {
    fut1().await?;
    fut2().await?;
    Ok(())
};

tryなしで動作させる代わりに。 しかし、船は出航してからずっと経っていると思います。

Re：自動ラッピング、今はasyncブロックと一貫性を保つことはできないと思います。 asyncブロックは、 Future実装する匿名型に、ある種の「自動ラップ」を行います。 しかし、これは、 tryブロックでは不可能な早期返品でも当てはまります。

架空のasync tryブロックがあるとしたら、二重に混乱する可能性があります。 結果を自動ラップする必要

自動ラッピングの意味で一貫性を保つ機会を失ったとは思いません。 どちらもasyncブロックと機能は使用することができます? 、両方とも自分の手動実行する必要がありますOk -wrapping、の両方早く、最終的なリターンを。

一方、 tryブロックは、自動Okラッピングで?を使用できます。これには、早期返品機能（おそらくラベルブレーク）を想定した「早期返品」も含まれます。値。 架空のtry関数は、早期リターンと最終リターンの両方で自動Okラッピングを簡単に実行できます。

架空のasync tryブロックは、2つのauto- Ok -wrap、次にauto- Future wrapの機能を単純に組み合わせることができます。 （逆の方法を実装することは不可能であり、とにかくtry asyncと書かれることは間違いありません。）

私が見ている矛盾は、 asyncブロックを関数と混同していることです。 （これはRFCとは逆に、最後の最後に発生しました。）これは、 asyncブロックのreturnがブロックを終了し、 try returnがブロックを終了することを意味します。 tryブロックは、含まれている関数を終了します。 ただし、これらは少なくとも単独では意味があり、early-returnまたはlabel-break-valueのないasyncブロックは使用するのがはるかに困難です。

これの安定化を止めるものはありますか、それともまだ誰もそれをするのに時間をかけていませんか？ それ以外の場合は必要なPRを作成することに興味があります🙂

2019年11月18日2時03分36秒AM PSTで、Kampfkarren [email protected]書きました：

これの安定化を停止するもの、または誰も取っていない
まだそれをする時間ですか？ 必要なPRの作成に興味があります
それ以外の場合🙂>
>>
->
あなたが言及されたのであなたはこれを受け取っています。>
このメールに直接返信するか、GitHubで表示してください：>
https://github.com/rust-lang/rust/issues/31436#issuecomment -554944079

はい、安定化へのブロッカーは、OKラッピングの決定を通じて機能しています。 これは、どのように動作するかについてコンセンサスが得られるまで安定化されるべきではありません。

私は個人的にOk-wrappingに反対していますが、事後に追加するのはどれほど難しいのだろうかと思っています。 no-ok-wrapping forwardはok-wrappingと互換性がありますか？

Result<Result<T,E>>のあいまいさなどのトリッキーなケースを想像できますが、そのようなあいまいなケースでは、ラッピングなしにフォールバックすることができます。 その後、ユーザーは明示的にOk-wrapして明確にすることができます。 この種のあいまいさがあまり頻繁に発生するとは思わないので、それはそれほど悪くはないようです...

Ok強制ではなく、 Okラッピングであるため、あいまいさはまったくありません。 try { ...; x }は、 Ok(x)同じように明確にOk({ ...; x })ます。

@joshtriplettこれは未解決ですか？ https://github.com/rust-lang/rust/issues/41414を引用して、追跡の問題にはチェックオフされたresolve whether catch blocks should "wrap" result valueがあります

@rpjohnst申し訳ありませんが、もっと明確にすべきでした。 つまり、Ok-wrappingを使用せずにtryを安定させた場合、後で互換性を持って追加できると思います。

つまり、ほとんどの人がtryブロックが必要であることに同意していると思いますが、すべての人がcatchまたはok-wrappingについて同意しているわけではありません。 しかし、私はそれらの議論がtryをブロックする必要はないと思います...

@Kampfkarrenはい。 上記の会話は、この問題の進行を詳しく説明しています。 全員に十分に相談することなく、時期尚早にチェックされました。 特に@joshtriplettには懸念があり、他の何人か（私を含む）がそれを共有しました。

@ mark-im将来、Ok-wrappingがどの程度正確に追加されると思いますか？ 私はそれがどのように行われるのかを理解しようとしていますが、私はそれを完全に見ることができません。

だから私はそれが良い考えかどうかわからないということでこれを前置きします...

ok-wrappingなしでtryブロックを安定させます。 例えば：

let x: Result<usize, E> = try { 3 }; // Error: expected Result, found usize
let x: Result<usize, E> = try { Ok(3) }; // Ok (no pun intended)

後で、Ok-wrappingを使用する必要があるというコンセンサスが得られたとすると、以前は機能しなかったいくつかのケースを許可できます。

let x: Result<usize, E> = try { 3 }; // Ok
let x: Result<usize, E> = try { Ok(3) }; // Also Ok for backwards compat
let x: Result<Result<usize, E1>, E2> = try { Ok(3) }; // Ok(Ok(3))
let x: Result<Result<usize, E1>, E2> = try { Ok(Ok(3)) }; // Ok(Ok(3))

問題は、これが以前にはなかった何かを曖昧にする可能性があるかどうかです。 例えば：

let x = try { Err(3) }; // If x: Result<Result<T1, usize>, usize>, then it is not clear if user meant Ok(Err(3)) or Err(3)...

しかし、おそらくOKラッピングはすでにこの問題に取り組む必要がありますか？

とにかく、私の直感では、そのような奇妙なケースはそれほど頻繁には発生しないので、それほど重要ではないかもしれません。

返されるタイプがResultまたはOptionである場合を除いて、Ok-wrappingを使用するのはどうですか？ これにより、ほとんどの場合、より単純なコードが可能になりますが、必要に応じて正確な値を指定できます。

// Ok-wrapped
let v: Result<i32, _> = try { 1 };

// not Ok-wrapped since the returned type is Result
let v: Result<i32, _> = try { Ok(1) };

// not Ok-wrapped since the returned type is Result
let v: Result<i32, _> = try { Err("error") };

// Ok-wrapped
let v: Option<i32> = try { 1 };

// not Ok-wrapped since the returned type is Option
let v: Option<i32> = try { Some(1) };

// not Ok-wrapped since the returned type is Option
let v: Option<i32> = try { None };

Ok -coercionまたは構文に依存するOk -wrapping（これは、それなしで安定化をサポートし、後で導入するために必要なことです）を追加すると、読みやすさが非常に悪くなります。 i.rl.oで何度も広く議論されてきました（一般的に、実装されている単純なOkラッピングを誤解している人々によって）。

私は個人的には実装されたOkラッピングに強く賛成ですが、ラッピングが困難になる状況を理解することを困難にするあらゆる形式の強制または構文依存にさらに強く反対します（役に立たないものを書かなければならないでしょう） Ok(...)は、強制されているかどうかを確認する必要があります）。

let x = try { Err(3) }; // If x: Result<Result<T1, usize>, usize>, then it is not clear if user meant Ok(Err(3)) or Err(3)...

しかし、おそらくOKラッピングはすでにこの問題に取り組む必要がありますか？

いいえ、それは明確にOk(Err(3)) 、 Ok wrappingは構文や型に依存せず、ブロックの出力がTry::Okバリアントにあるものは何でもラップするだけです。

@ mark-im安定した後、一方から他方に合理的に移動できるとは思いません。 Ok-wrappingは悪いと思いますが、必要かどうかを推測しようとする一貫性のないOk-wrappingはさらに悪化します。

私のコードベースでは多くのオプション値を扱っているので、ずっと前にマクロのような独自のtryブロックを導入しました。 そして、私がそれを紹介したとき、私はOk-wrappingの有無にかかわらずさまざまなバリエーションを持っていました、そしてOk-wrappingバージョンは非常に人間工学的であることが判明したので、それは私が使用することになった唯一のマクロです。

使用する必要のあるオプションの値がたくさんあり、それらはほとんど数値であるため、次のような状況がたくさんあります。

let c = try { 2 * a? + b? };

Ok-wrappingがないと、実際のtryブロックを使用するよりも、自分のマクロに留まる可能性が高くなるほど人間工学的ではありません。

この追跡問題の由緒ある歴史、 ?演算子との元々の残念な対立、およびOkラッピング問題の障害を考えると、この問題を完全に閉じてtryを送信することをお勧めします。

OKラッピングがないと、人間工学的ではありません。

それが導入する正確に非人間工学的なものについて詳しく教えていただけますか？

Ok-wrappingがない場合、例は次のようになります。

let c = try { Ok(2 * a? + b?) };

これは私の意見ではかなり良いです。

つまり、このような小さな例では、やり過ぎのように見えるかもしれませんが、 tryブロックに含まれるコードが多いほど、このOk(...)ラッパーが引き起こす影響は少なくなります。

@CreepySkeletonのコメントに加えて、 tryブロックがそれを行わない場合、 Okラッピングをエミュレートするマクロを作成するのは非常に簡単であることに注意してください（そして誰かが確実に作成します）この小さなマクロの標準的なクレート）ですが、その逆はそうではありません。

Try特性が不安定な間は、このマクロは使用できません。

どうして？ とにかく、それが安定するとき（仮想的にはそれほど遠くない将来）、それは非常に可能です。

Nemo157 @ tryブロックの夜間のみ、今でもある、と彼らはおそらく、我々はリッピングすることを決定したとは考えにくい場合には、安定化されることはありませんTry 。 これは、 Try前に安定化されない可能性が高いことを意味します。 したがって、マクロが不可能であると言っても意味がありません。

@KrishnaSannasiなぜTryがはぎ取られるのか

@ mark-imそうなるとは思いませんが、ブロックを試すために毎晩Tryが発生することを心配することが現実的な問題ではない理由を説明しています。 厩舎でTryを楽しみにしています。

?はすでに安定しており、 tryブロックは、 ?と同じように、 ResultとOption両方を含む明確な設計になっています。 ?はそうですが、 Try安定化でそれらの安定化をブロックするのを見ることができる理由はありません。 私はそれを注意深く見ていませんTryが、 tryブロックよりもTryのデザインについてのコンセンサスがはるかに少ないので、 try見ることができたという印象がありました。 Try特性の数年前に安定化をブロックします（ ? ）。 そして、たとえTry私はブロックする必要がない理由見ない特色に放棄されたtryブロックはただの作業として安定化されたResultとOptionのように?はそうなります。

（安定したtryブロックと不安定なTry特性が与えられた場合、そのマクロを記述できなかった理由は、マクロがtry { Try::from_ok($expr) }拡張されることです。タイプごとのマクロを作成できます。 ResultとOptionだけですが、IMOは「非常に簡単に[...]エミュレートする」という点を満たしていません）。

Tryトレイトは安定版では使用できませんが、 ?はすでに特殊なケースの安定版であるため、 Tryが不安定であるとtryブロックがブロックされる理由がわかりません。 Tryトレイトが削除された場合でも、人間工学がなくても、安定版で?をサポートするオプションと結果が残っているため、安定版に実装されています。

trycatchセマンティックについて次の概念を提案します...

次のコードについて考えてみます。

union SomeFunctionMultipleError {
    err0: Error1,
    err1: Error2,
}

struct SomeFunctionFnError {
    index: u32,
    errors: SomeFunctionMultipleError,
}

fn some_function() -> Result<i32, SomeFunctionFnError> {
    if 0 == 0 {
        Ok(2)
    } else {
        Err(SomeFunctionFnError{ index: 0, errors: SomeFunctionMultipleError {err1: Error2 {id0: 0, id1: 0, id3: 0}}})
    }
}

union OtherFunctionMultipleError {
    err0: Error1,
    err1: Error2,
    err2: Error3,
}

struct OtherFunctionFnError {
    id: u32,
    errors: OtherFunctionMultipleError,
}

fn other_function() -> Result<i32, OtherFunctionFnError> {
    if 0 == 0 {
        Ok(2)
    } else {
        Err(OtherFunctionFnError {id: 0, errors: OtherFunctionMultipleError {err0: Error1 {id0: 0, id1: 0}}})
    }
}

これは、次の構文機能を使用してRustのゼロオーバーヘッド例外によって生成される可能性のあるコードです。

fn some_function() -> i32 throws Error1, Error2 {
    if 0 == 0 {
        2
    } else {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    }
}

fn other_function() -> i32 throws Error1, Error2, Error3 {
    if 0 == 0 {
        2
    } else {
        Error1{id0: 0, id1: 0}.throw
    }
}

または、これらのエラーでさえ、コンパイラによって暗黙的に推測される可能性があります。

fn some_function(i: i32) -> i32 throws { // Implicitly throws Error1, Error2
    if i == 0 {
        2
    } else if i == 1 {
        Error1 {id0: 0, id1: 0, id3: 0}.throw
    } else {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    }
}

fn other_function(i: i32) -> i32 throws { // Implicitly throws Error1
    if i == 0 {
        2
    } else {
        Error1{id0: 0, id1: 0}.throw
    }
}

これは他に何も糖衣構文です!! 動作は同じです!!

こんにちは、みんな、

上記のゼロオーバーヘッド例外に関する私の提案を誰かが見たことがありますか？

@redradist tryブロックの主なポイントの1つは、ブロックごとに関数を作成する必要なしに、関数内で使用できることです。 私が見る限り、あなたの提案はここではまったく関係ありません。

ちょうど今日、私はtryブロックの必要性を感じました。 ?操作が多い大きな関数があります。 エラーにコンテキストを追加したかったのですが、 ?ごとに追加するには、膨大な量の定型文が必要でした。 tryエラーをキャッチし、コンテキストを1つの場所に追加すると、これを防ぐことができます。

ところで。 この場合、コンテキストに明確な有効期間がなく、ものを複数の関数に分割するとNLLが破損するため、内部関数で操作をラップするのは困難でした。

現在の実装では、 tryブロックは式ではないことを述べておきます。 これは見落としだと思います。

現在の実装では、tryブロックは式ではないことを述べておきます。 これは見落としだと思います。

うまくいかないコードを投稿していただけませんか？ ここで式のコンテキストで使用できます：（ Rust Playground ）

#![feature(try_blocks)]

fn main() {
    let s: Result<(), ()> = try { () };
}

確かに、ここにあります。

そして、これは、tryブロックの型推論がまだ完了していないことを示す別の例です。 タイプの帰属はif letブロックではサポートされていないため、これは特に厄介です。

@ Nokel81前の例の問題は、 if let $pat = $expr式が正規表現のコンテキストではなく、特別な「角かっこなしの式」コンテキストであるということです。 これが構造体式でどのように機能するかの例については、構造体式が存在することが構文的に明らかであるこの例と、存在しないこの例を参照してください。 したがって、エラーはtryが式ではないということではなく、エラーが間違っているということではなく、「 try式はここでは許可されていません。括弧で囲んでみてください」（および不要な括弧に関する誤った警告が抑制されました）。

後者の例は、実際には型推論に関してあいまいです。 この場合、 eのタイプは_: From<usize>です。これは、具体的なタイプを与えるのに十分な情報ではありません。 型推論を成功させるには、何らかの方法で具体的な型を指定する必要があります。 これはtry固有の問題ではありません。 Rustで型推論がどのように機能するかです。

ここで、すぐにOkとして照合し、 Errケースを破棄しようとすると、最適ではないエラーメッセージのケースがあり、それに対処するための実際の

ああ、詳細な説明をありがとうございました。 なぜ後で型推論が曖昧になるのか、私はまだ混乱していると思います。 式のタイプがResult<isize, usize>はないのはなぜですか？

?演算子は、 From特性を使用して、異なるエラータイプ間で型変換を実行できます。 これは大まかに次のRustコードに拡張されます（ Try特性を無視します）。

match expr {
    Ok(v) => v,
    Err(e) => return From::from(e),
}

From呼び出しは、最終的に返される式の型を使用して、実行するエラー型変換を決定します。デフォルトでは、渡された値の型に自動的に設定されません。

これがすでに対処されている場合はお詫びしますが、私には奇妙に思えます：

#![feature(try_blocks)]

fn main() -> Result<(), ()> {
    let result = try { // no type annotation
        Err(())?;
    };
    result.map_err(|err| err)
}

コンパイルに失敗する：

error[E0282]: type annotations needed

だが：

#![feature(try_blocks)]

fn main() -> Result<(), ()> {
    let result : Result<_, _> = try { // partial type annotation
        Err(())?;
    };
    result.map_err(|err| err)
}

大丈夫。

Resultの型引数を推測できなかったためにこれが問題だった場合は理解できますが、上記のようにそうではなく、rustcは次の結果が通知されると推論を実行できます。 try式は、ある種のResultであり、 core::ops::Try::into_resultから推測できるはずです。

考え？

@nwsharpは、 try / ?がTryタイプよりも一般的であるためです。 impl Try<Ok=_, Error=()>である他のタイプがある場合、tryブロックはResultと同様にそのタイプに評価できます。 脱糖、あなたの例は大まかに

#![feature(try_trait, label_break_value)]

use std::ops::Try;

fn main() -> Result<(), ()> {
    let result /*: Result<_, _>*/ = 'block: {
        match Try::into_result(Err(())) {
            Ok(ok) => Try::from_ok(ok),
            Err(err) => {
                break 'block Try::from_error(From::from(err));
            }
        }
    };
    result.map_err(|err| err)
}

@ CAD97説明ありがとうございます。

とは言うものの、 tryが異なるTry impls間で一種の変換を効果的に引き起こすことができるとは思っていませんでした。

into_result 、 from_ok 、およびfrom_errorに対して同じTry implが選択されるデサーガリングを期待します。

私の意見では、型推論を実行できないという人間工学的な損失（特に代替のimpl Tryが存在しないことを考えると）は、この変換を許可することの利点を上回りません。

私たちは、あいまいさを除去することにより、推論を可能とし、のようなものを経由してオプトインへの変換する能力を維持することができます：

try { ... }.into()

対応するブランケットimplを使用して：

impl<T: Try, E: Into<T::Err>> From<Result<T::Ok, E>> for T {
    fn from(result: Result<T::Ok, E>) -> Self {
        match result {
            Ok(ok) => T::from_ok(ok),
            Err(err) => T::from_err(err.into()),
        }
    }
}

（どの正直私は個人的に、ここでエラータイプの自動変換を疑うんが。それは望んでいたなら、ユーザーがすべき作るには、かかわらず有するセンスと仮定.map_err()上のResult 。）

一般的に、この脱糖は「賢すぎる」と思います。 それは隠しすぎており、現在のセマンティクスは人々を混乱させがちです。 （特に、現在の実装では、直接サポートされていないものに型注釈が要求されることを考慮してください！）

または、ブランケットimplをさらに進めて、私は推測します。

impl <T: Try, U: Try> From<U> for T 
    where U::Ok : Into<T::Ok>, U::Err : Into<T::Err>
{
    fn from(other: U) -> Self {
        match other.into_result() {
            Ok(ok) => Self::from_ok(ok.into()),
            Err(err) => Self::from_err(err.into()),
        }
    }
}

または何でも...

そうは言っても、tryが効果的に異なるTry impls間で一種の変換を引き起こすことができるとは思っていませんでした。

into_result 、 from_ok 、およびfrom_error同じTry implが選択されるデサーガリングを期待します。

私の意見では、型推論を実行できないという人間工学的な損失（特に代替のimpl Tryが存在しないことを考えると）は、この変換を許可することの利点を上回りません。

4つの安定したTryタイプがあります： Option<T> 、 Result<T, E> 、 Poll<Result<T, E>> 、およびPoll<Option<Result<T, E>> 。

NoneError不安定なので、 Option<T>にしようとして立ち往生しているOption<T>ながらNoneError不安定です。 （ただし、ドキュメントではFrom<NoneError>を「エラータイプに対してoption?を有効にする」と明示的に呼び出していることに注意してください。）

ただし、 Pollは、エラータイプをEに設定します。 このため、 Tryの「タイプモーフィング」は安定しています。 -> Result<_, E> ? Poll<Result<T, E>> -> Result<_, E>を取得して、 Poll<T>を取得できるからです。 Eケースを返します。

実際、これは「かわいい」小さなヘルパーに力を与えます。

fn lift_err<T, E>(x: Poll<Result<T, E>>) -> Result<Poll<T>, E> { Ok(x?) }

@ CAD97私をユーモアを交えてくれてありがとう。 これは、初心者に教えるのが難しいことであり、エラーメッセージに関してかなりの愛情が必要になります。

ここでの直感的でない動作を和らげるために、目的のimpl Try指定を許可することを考えましたか？

たとえば、少しバイクシェディング、 try<T> { ... } 。 それとも、それでもつまずく何かがまだありますか？

ここにもう少し色を追加するために、 Resultの束の上にtry { }がResult 「単に」生成しないという事実は予想外であり、私は悲しくなります。 理由はわかります

はい、「一般化されたタイプの帰属」（検索する用語があります）とtryの組み合わせについての議論がありました。 私が最後に聞いたのは、 try: Result<_, _> { .. }は最終的に機能することを意図していたと思います。

しかし、私はあなたに同意します： tryブロックは、それらの出力タイプが指定されていることを確認するためのいくつかのターゲット診断に値します。

Okラッピングの問題に関する言語チームのコンセンサスを解決するための特定の狭い質問については、この別の問題を参照し

コメントする前に、そのスレッドの冒頭のコメントを読んでください。特に、そのスレッドはその1つの質問に関するものであり、 tryまたは?またはTry関連する他の問題ではないことに注意してください。

tryブロックが必要な理由がわかりません。 この構文

fn main() -> Result<(), ()> {
    try {
        if foo() {
            Err(())?
        }
        ()
    }
}

これで置き換えることができます：

fn main() -> Result<(), ()> {
    Ok({
        if foo() {
            Err(())?
        }
        ()
    })
}

どちらも同じ文字数を使用していますが、2番目の文字はすでに安定しています。

結果を変数に割り当てる場合、結果を返すためにヘルパー関数を作成する必要があることを示している可能性があります。 それが不可能な場合は、代わりにクロージャーを使用できます。

@dylni tryブロックは、関数の本体全体が含まれていない場合に特に便利です。 エラー時の?演算子は、関数から戻らずに、フロー制御を最も内側のtryブロックの最後に移動させます。

`` `錆
fn main（）/ *ここに結果はありません* / {
結果=試してみましょう{
foo（）?. bar（）?. baz（）？
};
一致結果{
//…
}
}

@SimonSapinそれは

fn main() /* no result here */ {
    let result  = foo()
        .and_then(|x| x.bar())
        .and_then(|x| x.baz());
    match result {
        // …
    }
}

これはより冗長ですが、より簡単な解決策はメソッドクロージャ構文だと思います。

fn main() /* no result here */ {
    let result  = foo()
        .and_then(::bar)
        .and_then(::baz);
    match result {
        // …
    }
}

型はand_thenでも正しく推測されます。ここで、 try型注釈が必要です。 私はこれがあまり頻繁に出てこないので、簡潔な構文が読みやすさを損なう価値があるとは思わない。

受け入れられたRFCにはさらにいくつかの理由があります： https ：

とにかく、 and_thenようなチェーンメソッドよりも? （および.await ）演算子を使用した制御フローの言語構造を支持する議論はすでに広く議論されています。

とにかく、 and_thenようなチェーンメソッドよりも? （および.await ）演算子を使用した制御フローの言語構造を支持する議論はすでに広く議論されています。

@SimonSapinありがとう。 これとRFCを読み直すことで、これが役立つと確信しました。

tryブロックを使用して、エラーにコンテキストを簡単に追加できると思いましたが、今のところうまくいきません。

うまく機能する小さな関数を書きました。 File::open()?はstd::io::Error失敗し、次の行はanyhow::Error失敗することに注意してください。 タイプは異なりますが、コンパイラは両方をResult<_, anyhow::Error>に変換する方法を理解します。

fn tls_add_cert(config: &ClientConfig, path: impl AsRef<Path>) -> Result<(usize, usize), anyhow::Error> {
    let path = path.as_ref();
    let mut file = BufReader::new(File::open(path)?);
    Ok(config.root_store.add_pem_file(&mut file)
        .map_err(|_| anyhow!("Bad PEM file"))?)
}

エラーコンテキストを追加したかったので、try-blockを使用しようとしましたが、とにかくwith_context() ：

fn tls_add_cert(config: &ClientConfig, path: impl AsRef<Path>) -> anyhow::Result<(usize, usize)> {
    let path = path.as_ref();
    try {
        let mut file = BufReader::new(File::open(path)?);
        Ok(config.root_store.add_pem_file(&mut file)
            .map_err(|_| anyhow!("Bad PEM file"))?)
    }
    .with_context(|| format!("Error adding certificate {}", path.display()))
}

しかし、型推論は失敗します。

error[E0282]: type annotations needed
  --> src/net.rs:29:5
   |
29 | /     try {
30 | |         let mut file = BufReader::new(File::open(path)?);
31 | |         Ok(config.root_store.add_pem_file(&mut file)
32 | |             .map_err(|_| anyhow!("Bad PEM file"))?)
33 | |     }
   | |_____^ cannot infer type
   |
   = note: type must be known at this point
   ```

I don't understand why a type annotation is needed here but not in the first case. Nor do I see any easy way to add one, as opposed to using an [IIFE](https://en.wikipedia.org/wiki/Immediately_invoked_function_expression) which does let me add an annotation:

```rust
(|| -> Result<_, anyhow::Error> {
    let domain = DNSNameRef::try_from_ascii_str(host)?;
    let tcp = TcpStream::connect(&(host, port)).await?;

    Ok(tls.connect(domain, tcp).await?)
})()
.with_context(|| format!("Error connecting to {}:{}", host, port))

@jkugelman

再び、

これは、 try / ?がTryタイプよりも一般的であるためです。 [ impl Try<Ok=_, Error=anyhow::Error> ]である他のタイプがある場合、tryブロックはResultと同様にそのタイプに評価される可能性があります。

（また、 tryブロック（＃70941）で末尾の式をOkする必要はありません。）

これが現れ続けているという事実は、

• 安定化する前に、 tryはタイプアクリプション（ try: Result<_,_> {など）をサポートするか、この問題を軽減する必要があります。
• これには、 tryブロックの型推論が失敗した場合に、的を絞った診断が必要です。
• try 、他の制約がない場合は、 Result<_,_>へのタイプフォールバックを与えることを強く検討する必要があります。 はい、それは難しく、指定が不十分で、潜在的に問題がありますが、 $12: Try<Ok=$5, Error=$8>が十分に具体的でないため、 tryブロックが型注釈を必要とする80％のケースを解決します。

さらに、＃70941が「はい、（何らかの形式の）「 Try::from_okラッピング」が必要です」に向かって解決しているように思われる場合、 tryテール式の場合のターゲット診断も必要になる可能性があります。 xが機能するときに、 Ok(x)返します。

試してみるのに正しい振る舞いは

• 構文を拡張して、 try: Result<_, _> { .. } 、 try as Result<>などの手動による割り当てを許可します（ try: Resultはおそらく問題ないと思いますか？推奨される構文のようです）
• コンテキストから来る「期待されるタイプ」を調べます-存在する場合は、 try結果タイプとしてそれを優先します
• それ以外の場合、デフォルトはResult<_, _>これはi32ような型推論フォールバックではなく、以前に発生しますが、 try { }.with_context(...)ようなものがコンパイルされることを意味します。

ただし、少なくともエラータイプが指定されていない限り、 ?およびinto強制の前後でエラーが発生する可能性があるのではないかと心配しています。 特に、 tryブロックの結果を?するコードを書く場合は、次のようになります。

#![feature(try_blocks)]

use std::error::Error;
fn foo() -> Result<(), Box<dyn Error>> {
    let x: Result<_, _> = try {
        std::fs::File::open("foo")?;
    };

    x?;

    Ok(())
}

fn main() { 
}

どの?で「into」強制がトリガーされるべきかが明確でないため、エラー（遊び場）が発生します。

ここで最善の解決策が何であるかはわかりませんが、おそらく、私を緊張させる型推論のフォールバックが含まれます。

おそらく、私を緊張させる型推論のフォールバックが含まれます。

最も単純な方法：特定のTryブロックでの?すべての使用に、同じTry::Errorタイプが含まれている場合は、含まれているtryブロックにそのエラータイプを使用します（ただし、それ以外の場合はバインドされます）。

「（他に縛られていない限り）」はもちろん、微妙な怖い部分です。

私はこの投稿であまり建設的ではないことを願っています。 ただし、 @ nikomatsakisの例を、 ?が強制変換を行わず、 tryブロックの結果の自動ラッピングがないパラレルワールドの例と対比したいと思いました。

use std::error::Error;
fn foo() -> Result<(), Box<dyn Error>> {
    let x = try {
        std::fs::File::open("foo").err_convert()?;
        Ok(())
    };

    x?;

    Ok(())
}

この世界で：

• tryスコープとfn自体の両方が、値なしで成功することは簡単にわかります。 また、 Resultを生成しようとせずに、簡単に確認できます。
• エラー変換が発生する場所は明らかです。
• エラー変換をx?式に移動して、 tryスコープをstd::fs::File操作に固有にすることができます。
• すべてのタイプヒントは、タイプシグネチャから流暢に連鎖します。 機械と私たち人間の両方にとって。
• ユーザーによる型ヒントは、実際にエラーを別の独立したエラーに折りたたむ場合にのみ必要です。

私はそのパラレルユニバースでとても幸せです。

@phaylonあなたがそのコメントを注意深く書いた方法に感謝しますが、それはかなり非建設的であると思います。 エラー変換は?一部であり、変更されることはありません。それを考慮すると、ok-wrappingは基本的にこの説明の残りの部分と直交しています。

try関数（return型とthrow型）を検討する必要がある場合は、tryブロックを割り当てるための構文も同様のものと見なす価値があります。

例えば

try fn foo() -> u32 throw String {
  let result = try: u32 throw String {
    123
  };
  result?
}

これが議論されている場合は申し訳ありませんが、使用する利点は何ですか

try fn foo() -> u32 throw String { ... }

またはとは対照的に類似

fn foo() -> Result<u32, String> { ... }

？
構文が重複しているようです。

@gorilskij私が理解しているように、主な利点はOkラッピングを取得することです。 それ以外の場合は、次のように記述する必要があります。

fn foo() -> Result<u32, String> {
    try {
        // function body
    }
}

例外の用語が関連していると思うので、 throwsを好む人もいます。

個人的には、例外の出現をできるだけ避けたいと思います。

これはtry fnについて議論するスレッドではないので、この接線をこれ以上進めないでください。 このスレッドは、 tryブロックの受け入れられた機能のためのものであり、潜在的な（そしてまだRFCdではない）機能try fnではありません。

FromではなくIntoを使用して提案された?の

現在のRFCは、この目的のためにstd::convert::Intoトレイトを使用しています（ Fromからの包括的実装転送があります）。

正確なアップキャスト方法は未解決の質問として残していますが。 Intoは、（おそらく） Fromからのガイダンスに基づいて優先されました：

ジェネリック関数でトレイト境界を指定するときは、 Fromを使用するよりもIntoを使用することをお勧めします。 このように、 Intoを直接実装する型を引数として使用することもできます。

ただし、 TryトレイトRFCでは、 Intoは言及されなくなり、代わりにFromを使用して変換が行われます。 これは、 ?場合でも、コードが現在使用しているものでもあります
https://github.com/rust-lang/rust/blob/b613c989594f1cbf0d4af1a7a153786cca7792c8/src/librustc_ast_lowering/expr.rs#L1232

IntoからFrom移行する包括的な実装がないため、これは残念なことのようです。 つまり、（ Fromではなく） Intoを実装するエラーは、レガシーの理由で、またはその他の必要性から、 ? （またはTry ）。 また、標準ライブラリで推奨されている範囲内でIntoを使用する実装は、 ?使用できないことも意味します。 例として、標準ライブラリは私が書くことを推奨しています：

fn with_user_err<E>(op: impl Fn() -> Result<(), E>) -> Result<(), MyError>
where E: Into<MyError>

しかし、そうすると、関数本体で?を使用できなくなります。 それをしたいのなら、私は書かなければなりません

fn with_user_err<E>(op: impl Fn() -> Result<(), E>) -> Result<(), MyError>
where MyError: From<E>

しかし、そうすると、 From代わりにIntoを実装するエラータイプのユーザーはこの関数を使用できなくなります。 From基づくIntoの包括的実装のため、逆は真ではないことに注意してください。

今すぐ?を修正するにはおそらく（？）遅すぎます（これは_非常に_残念です—おそらく次の版では？）が、少なくともTryでそのパスを深く掘り下げないようにする必要があります

@jonhoo @cuviperは、＃38751をチェックするために＃60796で脱糖をFromからIntoに変更しようとしましたが、 From原因で、大量の推論が破損しました。 -> Intoブランケットimplは、rustcがID変換の一般的なケースを処理するのを難しくしました。 コストを破る推論はそれほど価値がないと判断されました。

@jonhooまた、有益であることがわかるかもしれません：

特性システムにはハードコードされた制限もあります。 ?X: Into<ReturnType>ような目標を解決する必要がある場合、解決に失敗しますが、 ReturnType: From<?X>ような目標を解決する必要がある場合、成功して?X値を推測する可能性があります。

編集：ここで、 ?Xはいくつかの未知の推論変数を参照しています。 今日の特性システムでハードコードされた制限は、そのオプションを検討するために、 Selfタイプを少なくとも部分的に推測する必要があるということです。

TL; DRは、 Intoて推測するのが難しく、特性ソルバーが機能する方法に固有の方法であるということです。

@KrishnaSannasi @ CAD97ありがとう、それは役に立ちました！ Into実装者を永久に除外していることを考えると、 From基づく安定化が進みすぎるのではないかと心配しています。 ここでの推論は最終的には良くなるかもしれないという期待はありますか？ 範囲内でIntoを優先するガイダンスを変更する必要がありますか？ 1.41の新しい特性コヒーレンスルール（そうだったと思います）では、 Intoだけを実装する理由がなくなり、それらすべてのimplsバグを考慮することを期待していますか？

推論が十分にうまくいく場合は、後でIntoに変更するために上位互換性があるはずです。 FromがInto意味することを考えると、私たちが破ることができる最悪の事態は推論です

これ（ Try特性）は、 ?がTryを実装する型の一般的な境界を持つInto / From特性と連携できるようにすることをカバーしていますか？ Try （例： Result自体）？

つまり、 ?などを返すクロージャまたは関数のimpl Into<Result>

（毎晩それを試してみるとそうではないようですか？）

私はこれが安定するのを見たいと思っています。 このスレッドと＃70941を読んだら、要約を次のように更新する必要があると思います。

1. 「catchブロックが結果値を「ラップ」する必要があるかどうかを解決する」にチェックマークを付ける必要があります。 「

2. これらの推論の問題について新たな懸念が追加されました。 おそらく次のようなものです：

   • []型推論の問題による人間工学的困難。

この最後の懸念は、とりわけ次の方法で対処できるというISTM：

• 安定化する前に、特注タイプの暗号化構文をtryに追加します
• https://github.com/rust-lang/rfcs/pull/803＃23416（Type ascription）がこれに対処し、最初に安定化する必要があることを決定し
• ある種の自動フォールバックを追加します（たとえば、 https： //github.com/rust-lang/rust/issues/31436#issuecomment -614735806で提案されているように、 Result ）
• tryを現状のまま安定させることを決定し、将来の改善のために構文/意味空間を残します

（これらのオプションの一部は相互に排他的ではありません。）

ご清聴ありがとうございました。このメッセージがお役に立てば幸いです。

タイプアクリプションには多くの問題（構文およびその他）があり、安定化は言うまでもなく、すぐに実装される可能性は低いようです。 タイプアクリプション構文でtryブロックをブロックすることは適切ではないようです。

Resultへのフォールバックは役立つかもしれませんが、エラー型の型推論の問題は解決しません。 try { expr? }? （または実際にはより複雑な同等物）には、実質的に.into()への2つの呼び出しがあります。 、これにより、コンパイラは中間型に対して柔軟性が高くなりすぎます。

@ijacksonは、現在の状態を要約するために率先して

ただし、型の割り当てに関しては、実装の課題はそれほど難しくないと思います。 それは、注意を向けて、それをフィニッシュラインに押し上げようとするのに良い候補かもしれません。 構文やそのようなものについて多くの論争があったかどうかは覚えていません。

2020年8月5日水曜日02:29:06 PM -0700に、ニコ・マサキスは次のように書いています。

ただし、型の割り当てに関しては、実装の課題はそれほど難しくないと思います。 それは、注意を向けて、それをフィニッシュラインに押し上げようとするのに良い候補かもしれません。 構文やそのようなものについて多くの論争があったかどうかは覚えていません。

私が思い出したように、主な関心事はタイプの帰属を許可することでした
どこでも文法が大幅に変更され、場合によっては
1つを制限します。 私は完全な詳細を思い出しません、ただ懸念があったということだけです
上げた。

個人的には、人間工学的な問題はそれほど悪くはないので、今この機能を安定させる価値はないと思います。 式タイプの割り当てがなくても、letバインディングを導入することはそれほど醜い回避策ではありません。

また、 tryブロックはマクロで役立つ場合があります。 特に、 @ withoutboatsの優れたfehlerライブラリは、 tryラップできれば、マクロシステムの欠陥に関する問題が少なくなるのではないかと思います。

トライブロックをたくさん使いたいところに出くわします。 これを一線を越えて取得するのは良いことです。 個人的には、試行ブロックを取得する必要がある場合は、絶対に100％犠牲タイプのアクリプションを使用します。 「ここにタイプアクリプションが欲しい」と言った状況にはまだ気づいていませんが、試行ブロックをシミュレートするためにIIFEを実行することになります。 別の長期的で不安定な機能と競合するため、長期的で有用な機能を不安定なままにしておくことは、本当に不幸な状況です。

もう少し具体的に言うと、Resultを返す関数内にいるときにこれを実行していることに気付きますが、Optionを返すものに対して何らかの処理を実行したいと思います。 とは言うものの、Tryが一般的に安定している場合は、実際にはmain関数から戻りたくないので、tryブロックを好むでしょうが、代わりに、チェーン内のいずれかが安定している場合は、何らかのデフォルト値を指定します。なし。 これは、シリアル化スタイルのコードで発生する傾向があります。

個人的に、私はブロックを試すよりもはるかに頻繁にタイプの帰属を望んでいました（私は時々両方を望んでいましたが）。 特に、コンパイラが予想とは異なる型を推測する「型のデバッグ」に苦労することがよくあります。 通常、どこかに新しいletバインディングを追加する必要があります。これは非常に混乱を招き、rustfmtが元に戻す履歴を壊してしまいます。 さらに、タイプの帰属が余分なターボフィッシュを回避する場所がたくさんあります。

対照的に、and_thenまたは他のコンビネータを使用して、終了せずに早期に終了することができます。 おそらく、ブロックを試すほどクリーンではありませんが、それほど悪くはありません。

@steveklabnik @ mark-im Tryブロックと型の割り当ては、決して競合していません。機能の問題ではありません。 tryブロックには非人間工学的な型推論の失敗があり、一般化された型の帰属はその問題を解決する方法である可能性がありますが、一般化された型の帰属は短期的な機能ではなく、確実なものでもないため、 @ joshtriplett （および私同意する）この機能が一般化された型推論の発生をブロックすることを望まない。

これは、一般化されたタイプの帰属を問題の解決策にしないという意味でもありません。 調査に値する1つのオプションは、「いつか一般化されたタイプの帰属がその問題を解決することを期待して、試行をそのまま安定させる」ことです。 言われていることは、型の帰属の安定化を妨げないことです。

@ rust-lang / lang GitHubやここで説明する他の多くの主題の制限のため、このスレッドからの型推論の失敗のニュアンスを理解するのは少し難しいことを認めなければなりません。 推論の失敗をどのように処理するかを決定することが、tryブロックの安定化を妨げる唯一のことなので、これについて話し合うための会議があれば有益だと思います。誰かが推論の問題を深く理解するためのポイントを得ることができます。 。

たとえば、私に発生する1つの質問は、この推論の問題は、特にTry許可されている変換の柔軟性によるものですか？ 決定が死ぬまで議論されたことは知っていますが、そうであれば、これはTry特性の定義を変更することを正当化できる適切な新しい情報のように思われます。

@withoutboats私は、すべての情報を1か所に収集する必要性と、この機能をフィニッシュラインに押し上げたいという願望に同意します。 とは言うものの、前回ここで調査したときに、下位互換性のためにTryへの変更が難しい可能性があることも明らかになったと思います- @ cramertjはいくつかの特定のPin impl、IIRCについて言及しました。