「return」を使用すると、ラベル付けされた? （tryop質問マーク演算子thingy）に興味深い影響があります。

SoniEx2 2018年02月28日

breakの代わりにreturnをキーワードとして使用しますか？

@ mark-imと@joshtriplettはすでに返品に反対しているが、それでも明らかに未解決の質問であることを

break（およびcontinue）は、ループでのみ使用できます。
あなたが何かを壊すことができれば、あなたはそれを続けることができます。（ブロックで続行するために選択する明確な構文はないと思います。）

C、C ++、Java、C＃、JavaScript、およびおそらくより多くの言語では、フォールスルーを防ぐために、通常、switchステートメントをbreakています。 Rustは|でこれをはるかにうまく解決しましたパターンではありますが、それらの言語から来た人々は、実際にはbreakをforループ専用のものとは見なしません。特に、JavaとJavaScriptなどを経由して機能を公開break良くないとしてreturn 。

ただし、「覚えておくべきルール」の議論は、他の方向にもうまく機能します。私が言えることから、returnが関数にのみ適用され、他には何も適用されないのは、言及された言語とRustの共通性です。したがって、リターンが表示された場合は、関数が残っていることがわかります。

ブロックにラベルを付けても、既存のラベルのないブレークでエラーは発生しません

まず、ラベル付きのブレーク機能は確かに1000行あたり10回使用されるものではないため、これが発生することは非常にまれだと思います。結局のところ、これはブロックの境界を越えるラベルのないブレークにのみ適用され、ブロック内のラベルのないブレークには適用されません。第二に、Rustのユーザーは、コンパイラによる苦情/エラーメッセージに慣れているので、喜んで修正します。 3番目（これが私が思う最強のポイントです）、ブロックにラベルを付ける代わりにループにラップする場合、ラベルのないブレークに注意する必要があり、ブレークステートメントを便利にリストするエラーメッセージがない場合は、次のようになります。自分でそれらを探すために:)。

est31 2018年03月01日

👍2

特に、JavaとJavaScriptは、ブレークを介して機能を公開し、戻りません。

これが私にとってのキラーポイントです。ブロックからの脱却は多くの言語でのことです。ブロックから戻る...それほど多くはありません。

nikomatsakis 2018年03月01日

👍4

個人的に、Iシェア@joshtriplettの使用上のビューbreakの代わりにreturnあなたが質問を信じるならば議論は... RFCに解決されていなかったように、それは私には思えましたlangチームで解決されたら、メモでボックスにチェックマークを付けます=）

Centril 2018年03月01日

私はこれに取り組んでいると言っているだけです。メンターの指示は必要ありません。努力を複製しないためだけに。すぐにPRを期待してください。

est31 2018年04月15日

🎉3

私はまだbreakよりもreturnに賛成ですが、ここでは同意しないことに同意できます。質問は解決しました。

scottmcm 2018年04月15日

❤3 👍2

現在（ rustc 1.28.0-nightly (a1d4a9503 2018-05-20) ）rustcは、ラベル付きブロックでunsafeを許可していません。これは期待されていますか？

topecongiro 2018年05月22日

@topecongiroはい、これは現在、プレーンブロックでのみ許可されていることを意図していると思います。将来変更される可能性がありますが、これは非常に低レベルで珍しい機能であるため、制限ではなく機能である傾向があります。（極端な場合、私は確かにelse 'a: {望んでいません。）

scottmcm 2018年05月22日

👍3

間違いなく同意します。安全でない+異常な制御フローは、落胆させるもののように聞こえます。

ただし、ピンチでは、次を使用できます。

'a: {
unsafe {...}
}

右？

mark-i-m 2018年05月22日

👍2

実際、他の方法では、新しい字句スコープが作成されます。これはブロックではありません。 if-else全体がブロック（ちょっと）です。いいえ、 else 'a: {は取得できません。 'a: if ... else {取得します。

SoniEx2 2018年05月22日

elseにはブロック（式）
elseよりもさらに悪い表面構文位置は'a: while foo 'b: {...}ます。
（興味深いことに、 continue 'aはbreak 'bです。少なくとも、内部的にはこれに依存することをお勧めします）

eddyb 2018年05月22日

❤1

（興味深いことに、 continue 'aはbreak 'bです。少なくとも内部的には、これに依存することをお勧めします）

それは素晴らしい観察です！

Centril 2018年05月22日

ラベルは、ブロック自体ではなく、ブロックを含む式の一部である必要があると思います。 loopでこれの前例がすでにあります。（たまたま、プレーンブロック自体もブロックを含む式です。しかし、 ifやloopものは、ブロックではなくブロックを含む式です。）

（ whileやforようなものは、正常に完了するかbreak完了するかに基づいて値を返すことができるかできないため、label-break-valueをサポートしないでください。。）

SoniEx2 2018年05月22日

@eddyb

（興味深いことに、続行 'a is break' b、少なくとも内部的にはそれに依存したい場合があります）

break 'bがループ状態を再チェックする場合のみ...

mark-i-m 2018年05月22日

@ mark-imこれは'a: while foo {'b: {...}}と同等であり、 breakはループ条件をチェックしません。ループ自体はループ条件をチェックします。これは、ループ条件が本体ブロックの各反復の前にチェックされるためです。

eddyb 2018年05月23日

うわー、私はそれを_非常に_直感的ではないと思います。 break 'bは基本的にgoto 'bであると思います。つまり、ループ本体を終了することはなく、条件が再度チェックされることもありません...

mark-i-m 2018年05月23日

ああ：man_facepalming：なるほど...

mark-i-m 2018年05月23日

これが私がbreak / continueというラベルの付いたものが好きではない理由です：/

mark-i-m 2018年05月23日

私は問題を見ていないので、まあ、我々は具体的には、これらの奇妙な内部ブロックをラベル付けすることはできません。 break常に「このブロックを離れる」ことを意味し、上記の制限を考えると、「関連する閉じ中括弧の後にスポットに移動する」以外の意味はありません。

rpjohnst 2018年05月23日

👍1

私の混乱は奇妙な内部ブロックに固有のものではありませんでしたが、私は本当に議論を再開したくありません。それはすでに起こっており、コミュニティはそれを追加することを決定しました。

mark-i-m 2018年05月23日

さて、私はアクセシビリティがプログラミング言語の大きな問題であることを理解しています...しかし、私のようなコードを書く場合、ラベル付きのブレークは非常に便利です。

では、どうすればラベル付きのブレークをよりアクセスしやすくすることができますか？

SoniEx2 2018年05月24日

❤1 😕1

では、どうすればラベル付きのブレークをよりアクセスしやすくすることができますか？

それは素晴らしい質問です。私が持っていたいくつかのアイデア：

人々が野生でこれをどのように使用しているかのサンプルをいくつか収集する必要があります。望ましくないパターンや怠惰な習慣を探すことができます。
ラベル付きのブレーク/コンティニューを使用するのが不適切であると考えられる場合は、スタイルについて意見を述べる必要があります。
機械的にループ/イテレーターコンビネーターに変換できるいくつかのパターンにリントを追加できる場合があります（ただし、頭のてっぺんからそのようなパターンは考えられません）。

最初の（明らかに偏った）サンプルとして、実際のコードでラベル付けされたブレークとの最後の（そして最初の）遭遇は恒星ではありませんでした： https ：//github.com/rust-lang/rust/pull/48456/files#diff-3ac60df36be32d72842bf5351fc2bb1dL51。元の作者がもう少し努力すれば、その場合はラベル付きのブレークを使用することを完全に回避できたはずです...これは、可能であればお勧めできない種類の練習の例です。

mark-i-m 2018年05月24日

それは...ブレークというラベルが付いていませんか？

rpjohnst 2018年05月24日

👍2

breakとcontinueこれにどのように脱糖するかについては、RFCの作成者による元のRFCの議論でも言及されていました。 https://github.com/rust-lang/rfcs/pull/2046#issuecomment-312680877を参照して

scottmcm 2018年05月24日

breakという名前は最適ではないと思いますが、forループは十分に確立されています。より「原則的な」アプローチは、構文return 'a valueを使用することです。これは、ブロック'a 「直後」に、そのブロックの値valueを使用して実行を続行します。

eddyb 2018年05月24日

@ mark-im「アクセスできないために機能を使用しない」とは、「その機能をアクセス可能にする」ことではありません。

ラベル付きのブレークを微調整して、言語の表現力を最大限に引き出すと同時に、脳がフロー制御のものやコンパイラーを処理できないという不満をやめるにはどうすればよいでしょうか。

（また、リンクしたコードはRFC 2046 / label-break-valueとは関係がないようです...おそらく間違ったコードをリンクしましたか？）

SoniEx2 2018年05月24日

それは...ブレークというラベルが付いていませんか？

（また、リンクしたコードはRFC 2046 / label-break-valueとは関係がないようです...おそらく間違ったコードをリンクしましたか？）

確かに、変更する前は「続行」というラベルが付いていましたが、同じ問題が存在すると思います（ルーチンの残りの部分の制御フローは、返す値によって影響を受ける可能性があるため、さらに悪化する可能性があります）。

@ mark-im「アクセスできないために機能を使用しない」とは、「その機能をアクセス可能にする」ことではありません。
ラベル付きのブレークを微調整して、言語の表現力を最大限に引き出すと同時に、脳がフロー制御のものやコンパイラーを処理できないという不満をやめるにはどうすればよいでしょうか。

申し訳ありませんが、文句を言うつもりはありません。私だけがこのように感じているのなら、私は脇に立ってもかまいません。

私見ですが、これは「ブレーク/コンティニュー」というラベルの付いた基本的な問題です。表現力が強すぎます。これを軽減する唯一の方法は、「良いスタイル」として推奨される使用法です（それが意味するものは何でも）。たとえば、「ループ本体の最初または最後（中央ではない）からの値を持つラベル付きブレークのみを使用してください。」これは、値を使用してループを終了するための可能な方法を簡単に見つけて推論できることを意味します。

mark-i-m 2018年05月24日

これは、他の言語でgoto / labeled breakを回避する方法です： https ：//gist.github.com/SoniEx2/fc5d3614614e4e3fe131/#file -special-lua-L4-L72

それはもっと読みやすいですか？

もしそうなら、おそらく私たちはラベル付けされたブロックに基づいてある種の条件付きシステムを理解することができます。同様に、この、多分。

SoniEx2 2018年05月24日

ラベルのないブレークアンドコンティニューのポイントは、条件/値をループヘッダーに簡単に配置できない場合に備えて提供することです。一部のループは、途中で中断するだけで、はるかに単純で、読みやすく、高速などです。

ループ内でのブレークとコンティニューのラベル付けのポイントは似ています-場合によっては、新しい変数、新しい関数（それによってreturnを悪用する）、または物事を追跡するのを難しくする他のゆがみを導入することが唯一の選択肢です。残念ながら、ラベル付きのブレークが複雑になっている可能性があります。

しかし、これら2つの機能は、このスレッドの目的ではありません。それらは、本質的に複雑な制御フローを表現するために提供される改善のために、かなり普遍的です。このスレッドは、代わりに非ループブロックから抜け出すことについてです。これは確かにもっと斬新で、ループの外側でbreakを探すことを知らない人もいるかもしれませんが、ラベルが必要な場合は、その意味がわかれば信号がまだそこにあることを意味します。

これは、あなたの例、@ mark-imについて私が意味したことです。これは、ラベル付きブロックではなく、ラベル付きループのかなり標準的な使用法でした。

rpjohnst 2018年05月24日

より「原則的な」アプローチは、構文return'a valueを使用することです。これは、そのブロックの値を使用して、ブロック 'aの「直後」に実行を継続します。

breakとreturnについての補足：静的制御フローであるため、 break方が好きです。 returnは動的であり、発信者に戻ります。発信者はどこにあってもかまいません。それは「私は自分の責任を果たしました。私が何をしているのかを見る場所は他にありません」という意味です。 breakは、ループの場合と同様に、常に字句的にスコープ内のどこかに移動します。

rpjohnst 2018年05月24日

👍8

return 'label exprは、 「exprを場所のラベルに戻す」と考えることができるという点で、「私が言うことを実行する」という観点からは非常によく読めると思います。この観点では、 break 'label expr同じようにうまく読めるとは思いません...

したがって、他のプログラミング言語とは別に、 return 'label expr提唱した可能性があります。ただし、他の言語での制御フローを考えると、 return再利用すると、突然実行可能なオプションがはるかに少なくなり、 break 'label exprを支持するようになります。

Centril 2018年05月24日

私はそれがbreak 'label exprではなくreturn 'label expr break 'label exprであるべきだという意見を固く信じています。そうしないと、ループでのbreak 'label既存の使用法と完全に矛盾します。

retep998 2018年05月25日

👍8

@ SoniEx2変数がループ不変条件を文書化する良い方法であることが主な理由で、私はあなたが投稿したスニペットを好むと思います。 OTOH、ラベルの名前でも同じことができるかもしれません（つまり、このラベル付きブロックが入力されるたびに、不変のPが保持されます）。これは、野生からのコードサンプルをもう少し持っておくとよい場所だと思います...

mark-i-m 2018年06月02日

安定化提案

この機能は@ est31によってhttps://github.com/rust-lang/rust/pull/50045に実装され、2018-05-16（+17週間）から毎晩使用されているため、安定化のために十分にベイクされています。また、これを実施したPRが統合されて以来、問題は報告されていません。それ以降、未解決の質問もすべて解決されており、 returnではなくbreakを表面構文にする必要があるという強いコンセンサスがあります。

したがって、私はlabel-break-value（RFC 2046）を安定させるために移動します。

@rfcbotマージ

報告する

フィーチャーゲート：
- https://github.com/rust-lang/rust/blob/master/src/test/ui/feature-gates/feature-gate-label_break_value.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/feature-gates/feature-gate-label_break_value.stderr
診断：https：//github.com/rust-lang/rust/blob/master/src/librustc_passes/diagnostics.rs#L285
テスト：
- https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs
- https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs

FCP前のTODO

@rfcbotはFIXME -in-testsに関係します

最後のテストファイルには現在FIXMEがあり

// FIXME: ensure that labeled blocks work if produced by macros and in match arms

これは、安定させる前に解決する必要があります。
期待される動作がwrtであることを確認するためにいくつかのテストを作成しました。 FIXMEは実際に実装されています：

// run-pass

#![feature(label_break_value)]

#[test]
fn lbv_match_test() {
    fn test(c: u8, xe: u8, ye: i8) {
        let mut x = 0;
        let y = 'a: {
            match c {
                0 => break 'a 0,
                v if { if v % 2 == 0 { break 'a 1; }; v % 3 == 0 } => { x += 1; },
                v if { 'b: { break 'b v == 5; } } => { x = 41; },
                _ => {
                    'b: {
                        break 'b ();
                    }
                },
            }
            x += 1;
            -1
        };

        assert_eq!(x, xe);
        assert_eq!(y, ye);
    }

    test(0, 0, 0);
    test(1, 1, -1);
    test(2, 0, 1);
    test(3, 2, -1);
    test(5, 42, -1);
    test(7, 1, -1);
}

#[test]
fn lbv_macro_test() {
    macro_rules! mac1 {
        ($target:lifetime, $val:expr) => {
            break $target $val;
        };
    }
    let x: u8 = 'a: {
        'b: {
            mac1!('b, 1);
        };
        0
    };
    assert_eq!(x, 0);
    let x: u8 = 'a: {
        'b: {
            if true {
                mac1!('a, 1);
            }
        };
        0
    };
    assert_eq!(x, 1);
}

// compile-fail

#![feature(label_break_value)]

fn lbv_macro_test_hygiene_respected() {
    macro_rules! mac2 {
        ($val:expr) => {
            break 'a $val;
        };
    }
    let x: u8 = 'a: {
        'b: {
            if true {
                mac2!(2);
            }
        };
        0
    };
    assert_eq!(x, 2);

    macro_rules! mac3 {
        ($val:expr) => {
            'a: {
                $val
            }
        };
    }
    let x: u8 = mac3!('b: {
        if true {
            break 'a 3;
        }
        0
    });
    assert_eq!(x, 3);
    let x: u8 = mac3!(break 'a 4);
    assert_eq!(x, 4);
}

提案されたFCPからFCPに移行する前に、これらと同様のテストを追加する必要があります。

Centril 2018年09月15日

チームメンバーの@Centrilは、これをマージすることを提案しました。次のステップは、タグ付けされた残りのチームによるレビューです。

[x] @Centril
[x] @aturon
[x] @cramertj
[x] @eddyb
[] @joshtriplett
[x] @nikomatsakis
[] @nrc
[x] @pnkfelix
[x] @scottmcm
[] @withoutboats

懸念：

費用便益（https://github.com/rust-lang/rust/issues/48594#issuecomment-422235234）
FIXME-in-tests（https://github.com/rust-lang/rust/issues/48594#issuecomment-421625182）
ユースケース（https://github.com/rust-lang/rust/issues/48594#issuecomment-422281176）

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

rfcbot 2018年09月15日

@rfcbotは費用便益に関係します

RFC FCP提案から：

別のグループは、言語に対するこの機能の「費用便益」は、完全には削減されていないと感じました。言い換えれば、機能がもたらす複雑さの増大-言い換えれば、人々が実際にそれを使用し、あなたが彼らのコードと言語の全体的なサイズを読まなければならない可能性-その有用性に見合ったものではありませんでした。

私はまだこの機能を持っているべきではないと思います。実装されてからたくさん使われていますか？使用した場合、関数を使用するのはかなり悪いですか？ここに利点がある場合、それは言語をより大きく、より複雑にするコストを上回りますか？

nrc 2018年09月18日

👍3

@nrc私は同じ懸念を共有しています。マクロがそれを使用できるようにそれを利用可能にするという議論は理解していますが、同時に、私はこれをまったく持っていたくありません。

私は、元のRFCスレッドから引数を更生する必要はありませんが、私は、これは、この機能での経験について尋ねるために合理的なポイントであると思います。それはどのような用途を見てきましたか？

joshtriplett 2018年09月18日

手書きのパーサー、ほとんど...（私は手書きのパーサーが好きです>。<）

labeld-propagate（ try_foo() 'bar? ）を使用すると、より便利で使いやすくなります。

SoniEx2 2018年09月18日

@rfcbotはユースケースに関係します

Discordに関するいくつかの議論の要約：実際のコードから、この機能を使用しないように書き直したときに、より明確に出会わない、このための具体的なユースケースを確認したいと思います。

joshtriplett 2018年09月18日

👍1

〜FWIW、私のEXPR is PAT実装は、少なくともASTで利用できるbreak 'label valueに依存していますが、それなしで脱糖がどのように機能するかはわかりません。
コンパイラでのEXPR?実装は、 break 'label valueにも依存しています。〜

〜これは、より大きな制御フロー機能のためのある種の基本的な構成要素であるため、とにかくコンパイラーに実装する必要があるかもしれません。
したがって、ここでの「コスト」は、おそらく表面構文で利用できるようにするだけです。

編集：私はこの問題を完全に誤解しましたが、これは約loop { ... break 'label value ... }であり、ブロック{ ... break 'label value ... }ではありません。
すでに実装されていることをいつも忘れているので、これを試す機会はありませんでした。

petrochenkov 2018年09月18日

@petrochenkovの確執に@joshtriplettに話し、彼らは、ユーザー向けの複雑さではなく、言語の実装について心配していたと指摘しました。

eddyb 2018年09月18日

複雑さの増加は最小限だと思います。読者にとって、概念はすでにループなどに存在するため、これが何を意味するのかは明らかです。
それ以外の場合は、無条件のbreakステートメントでループを使用する必要があります。これはあまり明確ではなく、実際、これについてはクリップのようなリント（never_loop）さえあります。ですから、メリットがあると思います。

ユースケースに関しては、そのトピックはすでにRFCに登場しています。ここで私のユースケースを指摘し直接リストされているユースケースも参照してください。たぶん、スレッドにはもっとたくさんあります、idk。 @joshtriplettはユースケースの質問を解決しますか？

est31 2018年09月18日

👍1

@nrcと@joshtriplettに同意します。また、ここでプロセスの懸念を提起したいと思います。 @ nrcと@joshtriplettが提起した質問を再検討すると、安定化がブロックされるという明示的な警告とともに、このRFCを暫定的に受け入れましたが、 @ Centril 'sマージ提案は、このブロッキングの懸念についてはまったく言及しておらず、これを非常に標準的な「機能が焼き付けられた」マージとして扱います。これについては@Centrilのせいではありませんが、プロセスの内訳です。安定化時に未解決のブロッカーを使用して機能を暫定的に受け入れる場合は、それらのブロッカーを追跡する必要があります。

プロセス全体の観点から、ブロッキングの懸念が提起されることなく2日半が経過し、ほとんどのチームメンバーがすでにチェックボックスをオンにしていることを確認することは私にとって心配でした。おそらく、すべてのメンバーの積極的なコンセンサスが不要になったため、ブロッカーを上げることなく、これがFCPに入る可能性があります。これは、RFCをマージすることに私を納得させた以前の合意の転覆のように感じます、そしてそれは完全に情報の不十分な追跡によって引き起こされたと思います。

withoutboats 2018年09月18日

❤2 👍1

@withoutboatsはい、その通りです。これにより、将来的には、「安定化プロセス中にXYZを実行する」という基準で物事を受け入れる傾向が弱まり、見逃される可能性が非常に低いプロセスが確立されるまで続きます。

joshtriplett 2018年09月18日

@withoutboats

これについては@Centrilのせいではありませんが、プロセスの内訳です。安定化時に未解決のブロッカーを使用して機能を暫定的に受け入れる場合は、それらのブロッカーを追跡する必要があります。

それにもかかわらず、お詫び申し上げます。私は警告に気づいていませんでしたが、それでも追跡の問題を作成したときにそのようなことをチェックする必要がありました。

これは、RFCをマージすることに私を納得させた以前の合意の転覆のように感じます、そしてそれは完全に情報の不十分な追跡によって引き起こされたと思います。

私はそれについて未解決の質問をするべきでした。その時点でプロセスミスが起こったと思います。
プロセスを改善する方法については、未解決の質問がRFCの_text_に到達することが重要だと思います。そうでなければそれらを見つけるのははるかに難しくなります;）

fcp-mergeプロポーザルについては; 個人的には、均一性の理由やマクロでの使用に役立つと思います。ただし、安定化を提案するには時期尚早であると思われる場合。提案をキャンセルしてください:)

Centril 2018年09月18日

@ est31

それ以外の場合は、無条件のbreakステートメントでループを使用する必要があります。

または、どちらかを回避するためにコードを再構築します。

ここで私のユースケースを指摘し

break 'pseudo_returnをreturn Ok(vectors);置き換えてみませんか？

joshtriplett 2018年09月18日

ここで述べたようます（labeled-propagate（ try_foo() 'bar? ）がなくても）。

label-break-valueを使用すると、関数型コードを簡単に必須化できます。一般に、命令型コードは関数型コードよりも読みやすい傾向があります。

SoniEx2 2018年09月18日

👍1

または、どちらかを回避するためにコードを再構築します。

もちろん、Rustは完全にチューリングしています。しかし、リストラは少し難しいかもしれません。全体として、「既存の方法を使用できる」という理由で、ほぼすべての砂糖機能（これは砂糖機能です）を拒否できます。

ブレーク 'pseudo_returnをreturnOk（vectors）;に置き換えてみませんか？

実際、この場合、あなたは正しいです、人は休憩をリターンOKに置き換えることができます。ただし、他の例では、後で処理を実行したい場合などがあります。ボローチェッカーは関数の境界を越えてうまく機能しないため、そのようなすべてのブロックを関数に組み込むことはできません。

とにかく、私は公式の手段で言語機能についてコメントすることについて沈黙を破りました、そして私はそれを後悔しています。すべて同じポイントで、何度も何度も再ハッシュされました。このたわごとは私の時間の無駄です、ごめんなさい。だから私からのこれ以上のコメントを期待しないでください。

est31 2018年09月18日

❤1

@ est31詳細を提供していただきありがとうございます。ありがとうございます。

joshtriplett 2018年09月18日

👍2

毎晩Rustが必要なため、これらをテストして使用するにはアクセシビリティの問題があります。

安定したターゲットです。これがいつか解決されることを願っています。

SoniEx2 2018年09月18日

ユースケースが必要な場合は、少し前にヒットしたものを次に示します。基本的に@ est31の「後で処理を行う」の詳細：C ++文字列リテラルプレフィックスを処理するレクサーを作成しました（実際のC ++の場合、{ L 、 u8組み合わせ爆発、 u 、 U 、} { R 、}）、および使用されるバイト数に「ギャップ」があるマルチバイトトークン（例）。 get_token関数は現在、次のようになっています。

fn get_token(&mut self) -> Token {
    match decode_byte(self.source) {
        // ...

        // repeat four times with small variations for b'U', b'L', and b'R':
        Some((b'u', rest)) => match decode_byte(rest) {
            Some((b'"', rest)) => self.string_literal(Utf16String, rest),
            Some((b'\'', rest)) => self.char_constant(Utf16Char, rest),
            Some((b'R', rest)) => match decode_byte(rest) {
                Some((b'"', rest)) => self.raw_string_literal(Utf16String, rest),
                _ => self.identifier(rest),
            },
            Some((b'8', rest)) => match decode_byte(rest) {
                Some((b'"', rest)) => self.string_literal(Utf8String, rest),
                Some((b'\'', rest)) => self.char_constant(Utf8Char, rest),
                Some((b'R', rest)) => match decode_byte(rest) {
                    Some((b'"', rest)) => self.raw_string_literal(Utf8String, rest),
                    _ => self.identifier(rest),
                },
                _ => self.identifier(rest),
            },
            _ => self.identifier(rest),
        },

        // ...

        // the "gap" mentioned above is here: single-byte '.' and triple-byte '...' but no double-byte '..':
        Some((b'.', rest)) => match decode_byte(rest) {
            Some((b'0'..=b'9', rest)) => self.number(rest),
            // note the _inner to avoid shadowing the outer `rest` used by the inner `Dot` case:
            Some((b'.', rest_inner)) => match decode_byte(rest_inner) {
                Some((b'.', rest)) => self.make_token(Ellipsis, rest),
                _ => self.make_token(Dot, rest),
            },
            _ => self.make_token(Dot, rest),
        },

        // ...
    }
}

_ => self.identifier(rest)のピラミッド（ u 、 U 、 R 、およびLに対して4回繰り返される）と_ => self.make_token(Dot, rest)注意してください。 identifier 、 string_literalなどすべてがmake_token呼び出さなければならない、一種の継続渡しスタイルを形成します。

break -from-blockを使用して、より継続性の低いスタイルに統合したいと思っていました。ほとんどの場合、ラベル付きのloopを使用して統合しましたが、そのバージョンはあまりにも奇妙で読みにくいと考えていました。具体的には：

私はすべてのmake_token呼び出しをメインのmatch decode_byte(self.source)後に単一の場所に移動し、それをインライン化しました-それは小さく、 unsafeを含み、その不変条件はget_tokenによって支持されています
"または'見つけたら、 break 'label self.string_literal(..)を使用して短絡し、すべてのself.identifier(..)呼び出しをそのマッチアームの最後に結合します。。
- プレフィックスの組み合わせ爆発を線形化することもできたかもしれませんu / u8 / U / Lをチェックしてから、 Rチェックしてくださいbreak 'labelは少なくなりますが、それでも少数です。
...見つけたら、 break 'label (Ellipsis, rest)を使用して短絡し、両方の(Dot, rest)をそのマッチアームの最後まで結合します。

全体として、これは基本的に「if +アーリーリターンを使用したフラット化された制御フロー」であり、別の関数に抽出する必要はありません。この場合、いくつかの理由でこれは非常に価値があります。

これらの関数のほとんどは、名前のない小さな使い捨て関数であり、この継続的なスタイルよりも読みにくくするためだけに機能します。
これらの関数のいくつかは、推測された型を持つ単純なローカルであるはずの追加のパラメーターの束を必要とします。
- または、代わりに、これらの場合のいくつかで借用チェッカーの問題を引き起こすクロージャ。
上で述べたように、ここでは機能全体で安全性の不変条件が支持されています。ここでの直線的で状態が機械的なコードであるほど、特に人々が後で戻って新しいトークンタイプに小さな変更を加える場合に適しています。

私は全部を書きますが、私はその試みを決してコミットしなかったと思います（おそらく私が上にリストしたすべての問題に遭遇したため）そして私はすでにここで十分な言葉を費やしました。 :)

rpjohnst 2018年09月18日

👍3

@SergioBenitezは、 http： //rocket.rs/のlabel_break_valueの使用法と、安定化についての見解について詳しく説明していただけますか？

Centril 2018年10月07日

@Centrilはい！要点は次のとおりです。

fn transform(request: &Request, data: Data) -> Transform<Outcome<_, _>> {
    let outcome = 'o: {
        if !request.content_type().map_or(false, |ct| ct.is_form()) {
            break 'o Forward(data);
        }

        let mut form_string = String::with_capacity(min(4096, LIMIT) as usize);
        if let Err(e) = data.read_to_string(&mut form_string) {
            break 'o Failure(FormDataError::Io(e));
        }

        Success(form_string)
    };

    Transform::Borrowed(outcome)
}

この機能を使用して、私は避けます：

ブロックを別の関数に分割して、早期の「リターン」を実現します。
ブロック内のすべての「戻り」値にTransform::Borrowedを追加します。
異なる場合に異なるTransformが返される場合、誤っている可能性があります。
- 注：これは、Rocketとこのコードに固有の不変条件です。

これが存在するのを見てとてもうれしかったです。これはまさに私が書きたいものです。そうは言っても、この機能に依存しないように、これを別の方法で明確に書くことができます。

SergioBenitez 2018年10月07日

❤2

@SergioBenitezありがとう！これを（最終的に） try { .. }書き直すことができるでしょうか？そのようです：

fn transform(request: &Request, data: Data) -> Transform<Outcome<_, _>> {
    Transform::Borrowed(try {
        if !request.content_type().map_or(false, |ct| ct.is_form()) {
            Forward(data)?;
        }

        let mut form_string = String::with_capacity(min(4096, LIMIT) as usize);
        if let Err(e) = data.read_to_string(&mut form_string) {
            Failure(FormDataError::Io(e))?;
        }

        form_string
    })
}

Centril 2018年10月07日

@Centrilええ、成功パスが1つしかない限り、それは機能します。これがここに

SergioBenitez 2018年10月07日

👍1

または、どちらかを回避するためにコードを再構築します。

これを行うと、オプティマイザーで解決できないブランチまたはサブルーチン呼び出しを追加するリスクがあります。私には、このような制御フローの変換はかなり複雑な作業のように思われます。

使用した場合、関数を使用するのはかなり悪いですか？ここに利点がある場合、それは言語をより大きく、より複雑にするコストを上回りますか？

小さな関数がインライン化されている場合もありますが、それでも、不要なコードの膨張が発生したり、愚かなコードの重複が発生したりします。

私は可能な限り最もエレガントなバイナリコードを好みます。これは、関数からの早期復帰とほぼ同じ、もう少し高度な制御フローによって行うことができます。

（最終的に）try {..}でこれを書き直すことができるでしょうか？そのようです：
[...]

最適化するためだけにブランチが導入されているため、これは少し混乱しているように見えます。ただし、状況によっては、両方が必要になる場合があります。したがって、

'a: {try{...}}

また

'a: try {...}

いいだろう。

この機能を使用しないように書き直したときに、実際のコードから、より明確に見出されない、このための具体的なユースケースを確認したいと思います。

お気軽に私を恥じてください：

最高のコードではないかもしれませんが、私は物事がまったく機能するようにしたかったのです。

継続渡しスタイルの観点から、メインループをステートマシンとして実験的に言い換えたいと思います。ただし、継続と強制末尾呼び出しは別のトピックです。

JohnBSmith 2018年10月31日

私が野生で見つけたいくつかの用途を捨てる：

Centril 2018年11月20日

👍2

この機能が安定しているのを見るのはとてもいいことです。この構文が意図を大幅に単純化および明確化する多くのユースケースがあります。フォールブル操作の実行とその結果のアンラップを含む長いセクションの場合、この構文は優れています。

zesterer 2018年12月03日

👍2

私は@zestererに同意し

repnop 2018年12月03日

👍4

FWIW、最近コンパイラで初めて使用しました。
パターンは前の例と同じです。複数の条件をチェックし、それらのいずれかが真である場合は実行を停止します。
https://github.com/rust-lang/rust/blob/21f26849506c141a6760532ca5bdfd8345247fdb/src/librustc_resolve/macros.rs#L955 -L987

petrochenkov 2018年12月03日

👍4

@ericktは、同じ理由でこれを使用したいコードもいくつか作成しました。複数の条件をチェックし、そのうちの1つがfalseになったらブレークアウトします。すぐに呼び出されるクロージャーまたはlet _: Option<()> = try { ... None?; .. };これを偽造することができますが、どちらもかなりハッキーです。

cramertj 2018年12月03日

@withoutboats @nrc @joshtriplettこれまでにさまざまな人々によってもたらされたユースケースについて何か考えはありますか？

Centril 2018年12月09日

Ping @withoutboats @nrc @joshtriplett ：）-前回のlangミーティングでは、上記の例のいくつかを書き直して、それらをどのように構成するかを示す可能性について話し合いました。

cramertj 2018年12月20日

❤1

グレイドンのブログ投稿に刺激を受けて、この機能を安定させたくない理由についてここにコメントを書きました。この実験に同意したのは少し不公平だと思います。ネガティブであることを証明するのは難しいですが、この形式の制御フローを言語に追加することへの反対をどのようなコードサンプルで克服できるかわかりません。

私の全体的な反対意見は、Rustがこれ以上のオープンエンドの分岐制御フロー構造を必要としないと単純に考えることです。一致とループがあり、それらの代数的データ型、シンタックスシュガー、関数抽象化、およびマクロに加えて、通常のユーザーが処理できる制御フローパターンの膨大な配列を作成します。これはすでに圧倒的な方向に進んでいるように感じます。私は個人的に、決定木の複雑さを管理するためにいくつかのルールを採用する必要がありました（たとえば、最初のパスとしてコンビネータに到達しないルールがあります。実際、それはコンビネータとしてより良いでしょう）。

Rustの制御フローツールボックスに、より広く適用可能で柔軟性の高い選択肢を追加することは避けたいと思います。私は、特定の重要なユースケースを対象とし、人間工学に大きな影響を与える制御フローを追加することにのみ関心があります。私の意見では、この構成は正確に逆の属性を持っています。それは広く適用可能で、非常に男性的であり、他の方法よりもわずかに便利です。

さらに、この機能にはもう1つの非常に悪い品質があると思います。それは、下位互換性による不規則性です。 breakがラベル付けされていないループから抜け出すときに、ラベル付けされている場合にのみブロックから抜け出すのは非常に不規則です。これにより、機能が通常の場合よりも理解しにくくなり、ネガティブな属性が最悪だと思う場所、つまり理解しやすさが悪化します。

また、焦点を当てるべきはるかに重要な機能がたくさんあると思います。これについては明確に分かれているので、この提案について長いコンセンサスプロセスを経るよりも、検討を延期したいと思います。

withoutboats 2018年12月27日

👍4 👎1

正しいことは、この機能を使用するすべてのクレートを見つけて、この機能を使用しないようにコードを書き直すことだと思います。

SoniEx2 2018年12月27日

👍1

@withoutboats私も同じ反対意見の多くを非常に効果的に表現していただきありがとうございます。

私は先に進んで、ここで大胆になります：

@rfcbotキャンセル
@rfcbot延期

joshtriplett 2018年12月27日

🎉2 👍1

@joshtriplettの提案はキャンセルされました。

rfcbot 2018年12月27日

チームメンバーの@joshtriplettは、これを延期することを提案しました。次のステップは、タグ付けされた残りのチームによるレビューです。

[] @Centril
[] @aturon
[] @cramertj
[] @eddyb
[x] @joshtriplett
[] @nikomatsakis
[] @nrc
[] @pnkfelix
[] @scottmcm
[x] @withoutboats

現在リストされている懸念はありません。

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

rfcbot 2018年12月27日

@withoutboats

Rustの制御フローツールボックスに、より広く適用可能で柔軟性の高い選択肢を追加することは避けたいと思います。私は、特定の重要なユースケースを対象とし、人間工学に大きな影響を与える制御フローを追加することにのみ関心があります。

私はこの原則に同意し、この機能はその基準を満たしていると思います（特定の重要なユースケースを対象とした使い慣れた制御フロー）。上記の例のようなコードを確認または記述したことが何度もありますが、これがこのコードを記述するための最もクリーンで読みやすい方法であると感じています。 loopような既存の制御フロー構造を再利用し、最後に無条件のbreakを付けると、ユーザーは誤解を招きます。また、 ? 、 await!を使用するため、すぐに適用できる関数では不十分なことがよくあります。

loop +末尾のbreakは混乱を招くため、代わりに、異なるスタイルの制御フロー用に作成されたツールを悪用するようにユーザーに要求するよりも、ユーザーに本当の意図を表明してもらうことをお勧めします。これは、他の言語がwhile true { ... }満足しているのに対し、 loop構造さえ持っているという事実に似ています。そうすることで、より明確な意図を表現し、結果としてより読みやすいコードを書くことが可能になります。

さらに、この機能は、Rustに常に期待されていたものです。これは、ラベル付けされたものとラベル付けされたものからのブレークを考慮した場合、ブロックにラベルを付けたり、ブロックを壊したりできないという事実は混乱を招きます。私には間違っています。

TL; DR：この機能は、ネストされたifステートメントを介して、またはloop-break-valueなどの他の構造を悪用することによってのみ記述できる、実際のユースケースをサポートしていると思います。これは、ブロックが期待どおりに動作するようにする表面構文への小さな追加であり、かなりハックなものではなく、私が意味するコードを記述できるようにします。

cramertj 2018年12月27日

👍10 ❤5

@cramertj申し訳ありませんが、少し混乱しています。あなたと@ withoutboats / @joshtriplettが正反対のことを言っているようですね。

（FWIW、私は@withoutboats / @ joshtriplettに同意します）

mark-i-m 2018年12月27日

@ mark-imこの機能を閉じる必要があることに同意しません。私はそれをマージする必要があると思います（私のコメントと上のチェックボックスで示されているように）。

私は@withoutboatsに同意します。特定の重要なユースケースに動機付けられていない、なじみのない新しいツールを追加するべきではないということです。この機能は親しみやすく、特定の重要なユースケースによって動機付けられていると思います。

cramertj 2018年12月27日

@withoutboats

この実験に同意したのは少し不公平だと思います。ネガティブであることを証明するのは難しいですが、この形式の制御フローを言語に追加することへの反対をどのようなコードサンプルで克服できるかわかりません。

私たちが設定した基準は、「label-break-valueでより適切に記述できるコードが存在しないことを示してください」ではないと思います。「label-break-valueが必要な特定のコードが別の方法でより明確に書かれています。」この会話は、あなたや他の人がこの機能が役立つ場所の動機付けの例を求めたときに始まり、このスレッドの多くの人々（私を含む）が例を提供しました。彼らはあなたや@joshtriplettに説得力がなかったので、私は今、あなたとあなたの両方がlabel-break-valueなしでこれらの例をどのように書くかを尋ねています。例がlabel-break-valueを使用してより適切に記述されていることに同意しますか？もしそうなら、ユーザーが潜在的に複雑なブロック破壊コードを書くことを許可するコストを上回るほど一般的ではないというあなたの立場はありますか？

cramertj 2018年12月27日

❤3 👍3

私は先に進んで、ここで大胆になります：

@rfcbotキャンセル

scottmcm 2018年12月27日

@scottmcmの提案はキャンセルされました。

rfcbot 2018年12月27日

ブロックがラベル付けされていないループから抜け出すときに、ラベル付けされている場合にのみ、ブロックから抜け出すのは非常に不規則です。

スレッドで言及されているかどうかはわかりませんが、ブロックがbreak;でターゲットにできないため、ある意味でラベル付きブロックはラベル付きloopよりも質的に強力になります。

ラベル付きブロックを使用すると、その内部でbreak;をサポートする制御フローマクロを作成できます。マクロインフラはユーザーには完全に見えません。
ラベル付きループでは、ラベルなしのbreak;が使用され、意図したターゲットではなく、以下のマクロによってキャッチされるリスクが常にあります。

私のEXPR is PATプロトタイプでは、最初は通常のloopを脱糖に使用しましたが、前述の問題のために問題が発生し、特にコンパイラをブートストラップできませんでした。
当時、ラベル付きブロックは実装されていなかったので、特別な「ターゲット不可能なloop 」をASTに導入し、脱糖に使用する必要がありました。

petrochenkov 2018年12月27日

👍4

私のチェックボックスで示されているように、私は今これを安定させることに賛成です。これは、マクロを容易にする言語の自然な拡張であり、機能パターンにあまり適合しない制御フローだと思います。 NLLによってライフタイムが非字句になりますが、タイプアクリプションと同じように、ブロックにライフタイムで注釈を付けることができることも、教育的に役立つと思います。

ただし、コンセンサスを得るのは難しいため、コンセンサスを見つけるために、 https：//github.comでの実験の作業をスピードアップするだけでなく、 try { ... }作業をスピードアップすることをお勧めします。 / rust-lang / rust / issues / 53667 （または@petrochenkovのEXPR is PAT構文と同時に）。

Centril 2018年12月27日

👍2

申し訳ありませんが、これの現在の状況はどうですか？私たちはFCPにいますか？

mark-i-m 2018年12月28日

@ mark-imラベルproposed-final-comment-periodまたはfinal-comment-periodいずれも問題になっていないため、FCPまたはその提案はありません。

Centril 2018年12月28日

👍1

（3つを除くすべてのチェックボックスをオンにしてFCPに入るという最初の提案がありましたが、FCPに参加したことはありません）

cramertj 2018年12月28日

👍1

@scottmcm

私は先に進んで、ここで大胆になります：

@joshtriplettの言葉遣いのこの繰り返しは、私が非常に皮肉だと読んだ。 langチームのメンバーとして、他の寄稿者とのコミュニケーション方法に注意してください。

withoutboats 2018年12月28日

😕2 👎1

実際、これは良い考えだと私は確信しています。私は以前、この機能に非常に反対していましたが、これはプログラマーが使用すべき機能ではないと思います。上記のユースケースはやや説得力がありますが、それでも小さな関数に組み込む方がよいと思います。私が本当に説得力があると思ったのは、マクロからの出力です。ユーザーがなんらかの方法でreturn挿入できる場合、これは関数への変換を排除します。しかし、私たちが本当に望んでいるのは、単純なgotoです。「大きな」解決策は、トークンではなく、HIRを出力できるマクロであるかどうか疑問に思いますが、それは少しあります。それまでの間、マクロの作者のためにこの機能があればいいので、バランスをとって安定させる必要があると思います。

nrc 2019年01月05日

❤1

誰かが物事をより遅く、直感的でなく、人間工学的でない方法で書き直そうとしたことがありますか？

ブロックを壊すのは人間工学的な後藤のようなものです。 gotoの問題はほとんどありませんが、同じくらい強力です。

SoniEx2 2019年01月05日

👍1

@nrcの心の変化に基づいて、私はlabel_break_valueを安定させるために移動します。
私のレポートはhttps://github.com/rust-lang/rust/issues/48594#issuecomment-421625182にあります。

@rfcbotマージ
@rfcbotはFIXME -in-testsに関係します

@joshtriplettと@withoutboatsがまだ抱えている懸念を提起する時間を確保するために、そのような懸念を記録します。彼らがそのような懸念を持っていないと私に言ったら、または彼らの一人が彼ら自身の懸念を提起したとき、私はそれを持ち上げます。

@rfcbotの懸念give-boats-and-josh-time-to-raise-any-concerns-they-might-still-have

この問題および他のすべての問題のプロセスノートとして、提案を前後にキャンセルすることは避けてください...何かが前進する必要がないと思われる場合は、懸念事項を使用してください。

Centril 2019年01月05日

チームメンバーの@Centrilは、これをマージすることを提案しました。次のステップは、タグ付けされた残りのチームメンバーによるレビューです。

[x] @Centril
[x] @aturon
[x] @cramertj
[x] @eddyb
[x] @joshtriplett
[] @nikomatsakis
[] @nrc
[x] @pnkfelix
[] @scottmcm
[] @withoutboats

懸念：

ブロッキング（https://github.com/rust-lang/rust/issues/48594#issuecomment-451673194）
FIXME-in-tests（https://github.com/rust-lang/rust/issues/48594#issuecomment-451672226）
~~give-boats-and-josh-time-to-raise-any-concerns-they-might-still-~~ https： //github.com/rust-lang/rust/issues/48594#issuecomment-451673282によって解決されました
https://github.com/rust-lang/rust/issues/48594#issuecomment-632960804によって解決された~~should-close-not-merge~~

レビューアの過半数が承認すると（そして最大2つの承認が未解決になると）、これが最終コメント期間に入ります。このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

rfcbot 2019年01月05日

@rfcbot懸念ブロッキング

私はすでに私の立場を表明しました。それは、Rustにこの機能を持たせるべきではないということです。これがプロジェクトにとって十分に高い優先順位であり、近い将来いつでもこの提案について合意に達するプロセスに従事することに時間を割くことができるとは思えません。

withoutboats 2019年01月05日

@rfcbotは、 give-boats-and-josh-time-to-raise-any-concerns-they-might-still-haveを解決します

Centril 2019年01月05日

重要な場合： Zigにもこの機能があります。

glaebhoerl 2019年01月05日

❤2

2019年1月5日午前9時18分29秒AM PSTで、マズダク教Farrokhzadの[email protected]は書きました：

@rfcbot解決
ボートを与えて、懸念を提起する時間を与える-彼らはまだ持っているかもしれない

私たちはすでに懸念を提起しており、それらは「これはその言語であってはならない」ということになります。それらの懸念は消えません。

私は、マクロがIRを生成できるはずであるというnrcの概念を好みます。これは、言語の表面的な構文に必ずしも追加することなく、これと多くの将来の可能性に対する完全に合理的な解決策のように思われます。

joshtriplett 2019年01月05日

@joshtriplett

私たちはすでに懸念を提起しており、それらは「これはその言語であってはならない」ということになります。それらの懸念は消えません。

明確にするために、私はそれらを@rfcbot登録することを意味しました。これは、提案がキャンセルされた後、ボットが登録された古い懸念を認識しないためです。私はあなたが懸念を持っていることを知っている

私は、マクロがIRを生成できるはずであるというnrcの概念を好みます。これは、言語の表面的な構文に必ずしも追加することなく、これと多くの将来の可能性に対する完全に合理的な解決策のように思われます。

それがどのように見えるのか、それがより良いアイデアであるのか、私にはわかりません。それはかなり推測的であり（「設計が合意されるまでに何年もかかるかもしれない」という意味で）、マクロの結果である以上の利点もあるbreak 'label exprのかなり低コストのソリューションよりもコストがかかるようです拡張。

Centril 2019年01月05日

👍2

_この問題および他のすべての問題のプロセスノートとして、提案を前後にキャンセルすることは避けてください...何かが前進する必要がないと思われる場合は、懸念事項を使用してください。_

私は確かにそれに同意します。ただし、ここでの適切なメカニズムは懸念事項ではないと思います。懸念は「これが解決されたら、私は承認するだろう」のようです。ここでの問題は、「これはまったく先に進まないはずです。「マージ」は間違ったターゲットです。代わりに「閉じる」ことを望みます」です。それは「懸念」のメカニズムによってうまく処理されないようです。

joshtriplett 2019年01月05日

@joshtriplett興味深い点として、あなたが以前に言及した提起された懸念に私を向けることができますか？私は元のRFCスレッドを調べましたが、具体的に何が参照されているのかわかりません。ありがとう。

zesterer 2019年01月06日

@rfcbotは、人間工学と最適化/パフォーマンスに関するものです（パフォーマンスと人間工学の低下の錆びない例https://gist.github.com/SoniEx2/fc5d3614614e4e3fe131#file-special-lua）

この権利を使用している場合はidk

（「脱糖」の一部（実際には脱糖とは正反対だと思います-gotoはプリミティブであり、脱糖をgotoにループします）が非常にひどいことに注意してください）

（luaにはラベルが付いていないため、gotoを使用する必要があることにも注意してください。それでも、少なくとも1つのブレークブロックが必要になると思いますが、おそらくよりクリーンな「脱糖」が必要です。）

SoniEx2 2019年01月06日

@rfcbotの懸念は

（ @centrilがDiscordで提案した

joshtriplett 2019年01月06日

これが安定化に賛成か反対かはわかりませんが、今日の安定したRustでエンコードするのは簡単です。

fn main() {
    'foo: for _ in 0..1 {
        println!("break");
        break 'foo;
        println!("broken");
    }
}

したがって、一方では、言語がほとんど成長しておらず、 for _ in 0..1省略しているため、これを安定させる必要があります。一方、今日は簡単な方法があるため、これを安定させるべきではありません（それは本当に必要です）そして私たちはそのようなアンチパターンの使用を奨励すべきではありません。

nrc 2019年01月07日

ちょっと紛らわしいようで、ラベルは不要です。

ブロックを壊すのははるかに混乱が少なく、ラベルが必要です。

ブロックを壊すことがアンチパターンだと思う理由がわかりません。 Xに適用されることは、必ずしもnot-quite-Xに適用されるとは限りません。私は299.99ドルでコンピューターを購入できるかもしれませんが、299.98ドルではなく、「基本的に」同じです。

SoniEx2 2019年01月07日

@nrc

これが安定化に賛成か反対かはわかりませんが、今日の安定したRustでエンコードするのは簡単です。
    'foo: for _ in 0..1 {
        break 'foo;
    }
したがって、一方では、言語がほとんど成長しておらず、 for _ in 0..1省略しているだけなので、これを安定させる必要があります。

'a: for _ in 0..1 { break 'a }は、明示的な目標が誰にも'a: { ... break 'a e; ... }書かせないことである場合に機能する可能性があります。ただし、ガベージIRを生成するという欠点があり、タイプチェッカー、MIR、およびLLVMが処理する必要があるため、コンパイル時間が悪化します（少なくともLBVと比較して）。

一方、今日（本当に必要な場合に）簡単に実行できる方法があるため、これを安定させるべきではありません。また、そのようなアンチパターンの使用を推奨するべきではありません。

LBVがアンチパターンであることに同意できないと思います。結局のところ、Rustを関数型プログラミング言語にするだけでなく、Rustに命令型の制御フローを吹き込むことを選択しました。私はそのような制御フローを持たない方がよかったかもしれませんが、それは事実です。問題は、LBVがRustの他の命令型メカニズムよりもどういうわけか読みにくいか問題があるかどうかです。そうではないと思います。

関数は短く（垂直に）浅く（インデント）に保つべきだと思いますが、長くて深いよりも長くて浅い方が良いです。 LBVは、より複雑なフローの一部で深さを回避するのに役立つことがわかりました。 LBVは、ジャンプ先を明示的に示し、フローをよく理解しているので、私にも読みやすいように見えます。全体として、LBVは最も問題の少ない命令型制御フローの1つであることがわかりました。

Centril 2019年01月07日

👍6

'a: for _ in 0..1 { break 'a }
'a: { ... break 'a e; ... }

これらは似ているように見えるかもしれませんが、まったく同じではありません。前者は間違いなくアンチパターンですが、後者は間違いなくそうではありません。

loop {}とwhile true {} （ loopは値を返すことができますが、 whileは返すことができませんが、少し無視しましょう）

SoniEx2 2019年01月07日

@nrcただし、まったく同じ動作はありません： https ：

特に、 break;とcontinue;は異なります。この架空のコードを考えてみましょう。

some_macro! {
   ...
   break;
   ...
}

some_macroが'a { ... }に展開される場合、 'a: for _ 0..1 { ... }に展開される場合とは動作が異なります。

Pauan 2019年01月07日

👍3 ❤2

@ SoniEx2

誰かが物事をより遅く、直感的でなく、人間工学的でない方法で書き直そうとしたことがありますか？

より積極的かつ生産的な方法であなたの懸念を伝えてみてください。他人を嘲笑しても私たちはどこにも行かず、人々は気分が悪くなります。 Rustが可能な限り最高のプログラミング言語であることを確認したいので、私たち全員がここにいます。そのプロセスの一部は、コミュニティが可能な限り前向きで励みになることを保証することです。

cramertj 2019年01月07日

おそらく、私はいくつかの大きな誤解に陥っています。私はLLVM、Rustの内部、または同様のものの専門家であるふりをしません。とは言うものの、私はコンパイラーの設計について基本的な経験を持っており、懸念事項について混乱しています。誰かが説明してくれたら本当にありがたいです。

私が物事を見る方法：

1）これはフロー制御の人間工学を変更しません。 Rustには、 'a: loop { if x { break 'a; } break; }などのこのような構造がすでに存在します。

2）これは、ブロックリターンの人間工学を特に変更するものではありません。ループはすでに値を返すことができます。

私には、これはRustがすでに持っている一連の機能の直感的な完成のように思えます-すべての（または少なくともそれ以上の）ブロックに対してそれらの機能を一般化します。

これがgotoにあまりにも似ているという懸念に関して、私はさらに混乱しています。これは、Rustでまだ可能ではないものを追加せず、後方ジャンプ（ goto使用が不十分でスパゲッティコードに回帰する主な問題）を許可しないため、失敗します。これは事実上、常に壊れているループの単なる構文糖衣であるように思われるため、この機能がcodegenにどのような影響を与える可能性があるかを理解するため。

誰かが私にもっと具体的な言葉でどんな問題が存在するか説明できますか？

zesterer 2019年01月07日

👍4

手続き上、IMOはconcern blockingまたはconcern should-close-not-mergeスタイルの懸念事項を提出することは適切ではありません。この懸念事項には、提案された機能の問題や、解決に向けて取り組むことができるものはリストされていません。 -それは単なるパーマブロッカーです。 rfcbotの懸念メカニズムを使用して機能を永続的にブロックする必要はないと思いますが、懸念の解決を追跡し、それらが適切に対処/解決されていることを確認するためにのみ使用する必要があります。プロセスについての私の理解は、チェックされていないチェックボックスを使用して不一致をマークすることであり、その懸念は、機能とその機能に関する特定の議論可能な問題を提出するために使用されることでした。

私が個人的に同意しなかった他の機能（たとえば、uniform_pathsを参照）について同様の「私はこれが好きではない」という懸念を提起することもできましたが、無限の議事妨害が言語設計を行うための生産的な方法であるとは思いません。

この機能が言語の他の部分と相互作用する方法について特定の懸念がある場合は、話し合い/解決する必要があります（たとえば、「これはtry { ... }によって回避できるようです」または「慣用的に大きな関数」）そのようにファイルする方が生産的だと思います。

cramertj 2019年01月07日

👍5

@cramertj @Centrilが明示的に提案していなければ、そのような懸念をその形式で提出することはなかったでしょう。（FCPが提案されていなかったら、私は個人的に好んでいたでしょう。）

誰かが「近い」以外の何かをrfcbotとP-FCPを提出した場合は、「これは閉じなければなりません」のための適切なプロセスとして何を示唆していますか？「適切に対処/解決されていることを確認してください」は、「これはいつか安定する予定ですが、そこに到達するには何が必要ですか？」と同等に聞こえます。それは、「これは決して安定化されるべきではなく、これは言語の一部であってはならない」という流れに道を残しません。

プロセスについての私の理解は、あなたの意見の相違をマークするためにチェックされていないチェックボックスを使用することを意図したということでした

次に、プロセスを元に戻して、続行するためにすべてのチェックボックスをオンにする必要があります。

私は、無限の議事妨害が言語設計を行うための生産的な方法であるとは思いません。

私もそうは思わない。私もこれを結論付ける道を見つけたいと思います。私はそれが別の方向に結論付けられることを望んでいます。

ちなみに、このRFCの経験に基づいて、「安定化中に続行するかどうかを評価/対処できる」という警告を付けてRFCに応答することは、私には明らかであるため、再度良い考えではないと思います。そうすることで、このような重大な手順上の問題が発生します。

「はい、この個々の機能がどのように言語をより表現力豊かにするかはわかりますが、言語の全体的な評価に基づいて、それはその重みを持たないので、これ以上拡張したくありません。このように言語の表面積」。提案されたすべての機能が何らかの形で不可避であり、反対意見を鎮め、持続するだけの問題であると見なされないよう

joshtriplett 2019年01月07日

❤2 👍2

見逃されているようですので、前に言ったことを繰り返します： //github.com/rust-lang/rust/issues/48594#issuecomment -451795597

基本的に、ループを使用する場合とブレークブロックを使用する場合の違いについて説明しました。

主に、ブレークブロックは異なる構文、（わずかに）異なるセマンティクス（少なくともラベルのないブレークに関して）、異なる意図、およびその他のいくつかのマイナーなことを意味します。

SoniEx2 2019年01月07日

rfcbotは懸念事項をサポートしていますか？

SoniEx2 2019年01月07日

@joshtriplett

「はい、この個々の機能がどのように言語をより表現力豊かにするかはわかりますが、言語の全体的な評価に基づいて、それはその重みを持たないので、これ以上拡張したくありません。このように言語の表面積」。提案されたすべての機能が何らかの形で不可避であり、反対意見を鎮め、持続するだけの問題であると見なされないように、定期的に電話をかける必要があると思います。

ええ、機能を受け入れるか拒否するかのどちらかが適切なチームの完全なコンセンサスを必要とすることは、私たちの現在のプロセスの不幸な危険です。 langチームが現在のように大きい場合、これを常に達成することは困難です-上記のコメントから、この機能が重要である理由を動機付けるためのコード例が欠落しているだけだと思いましたが、今ではそこに同意しているようですは、この機能を使用してより適切に記述できるコードですが、ここに表示されるコストに見合う価値があるとは確信していません。例（別のスタイルで書くことは文字通り不可能なマクロの例を含む）を提供し続けるだけでは十分ではないように思われるため、これらのケースが十分な動機であるとあなたに納得させる方法がわかりません。

同様に、私は個人的にこの機能をマージする必要があると確信しています。IMOは、それが最良/唯一のオプションであるさまざまな例を通してその重みを引き出すだけでなく、言語は実際には追加されてよりシンプルになります（他のラベル付きコンストラクトを許可することを考えると、ラベル付きブロックを許可しないことは私にとって驚くべきことです）。

私の上記のあなたの立場の要約に同意するなら、私たちは不幸なことに（そして、私は信じていますが、歴史的です！）プロセスを欠いているようです。 1つのオプションは、上記のように現在のrfcbotルールを解釈して、「チェックボックスがないことはあなたの意見の相違を示します。過半数を却下するには3人のメンバーが必要です」という意味ですが、ルールが導入されたときの意味はそうは思わないので、この手順に従うべきだと提案するのは私にとって不誠実だったと思います（私は他の場所でそれを自分で行いましたが）。

以前、承認済み->実装済み->安定化された機能に期限を設けることができ、バックログの増加を回避するために遅れる機能を「自動クローズ」する必要があるという提案を聞いたことがあります。そのようなものは、私（そして、私が思うに、チームの他の何人か）がチェックボックスを閉じるようにマークせず、あなたがチェックボックスを受け入れるようにマークしないというこのケースに対処することができます（私は今でも私がこれを言っても恐れていますmあなたを説得するための最後の努力を捨てる！：smile :)。

成長を続けるチームでは、機能についてコンセンサスを得ることができなくなり、特にlang-designチームでは、一貫した方法で言語を操作することが難しくなるのではないかと心配しています。チームのサイズ制限は、これに対する明らかな解決策のように思われます。多数の人々から意見を受け取ることは可能ですが、十分に大きなグループ間で絶対的なコンセンサスを構築することはまったく不可能です。他の人はおそらく、言語を誤った機能から保護するために、論争のある機能をマージすべきではないと主張するでしょう。個人的には、コミュニティが適切な警告なしにこれらの間違いの多くを犯すことを許す可能性は低いと思いますが、それは考えです。

ここでプロセスの進化について説明するために別のスレッドを開始します。それまでの間、このスレッドでチャイムを鳴らしている人は、とは著しく異なると見なす新しい重要なユースケースがある場合にのみ投稿してください。上記のもの、またはこの機能を言語に追加すべきではないという重大な考慮されていない理由がある場合。これらのメガスレッドの履歴全体を読むことは困難ですが、投稿が何度も繰り返されたり、スレッドが役に立たない解説でいっぱいになったりすると、さらに難しくなります。（彼は、スレッドXD全体で最も長いコメントの1つを入力したと言います）

TL; DR：行き詰まっていると思います。そのためのプロセスが必要です。その会話を別の場所で開始し、ここにリンクします。それ以外の場合は、考慮する必要のある重要な新しい情報がない限り、コメントしないでください。

cramertj 2019年01月08日

👍1

@cramertj

機能を受け入れるか拒否するかのいずれかが適切なチームの完全なコンセンサスを必要とすることは、現在のプロセスの不幸な危険です

私は正直にそれを機能と考えます。

上記のコメントから、この機能が重要である理由を動機付けるためのコード例が欠落しているだけだと思いましたが、この機能を使用してより適切に記述できるコードがあることに同意したようですが、それが価値があるとは確信していませんここに表示されるコスト。

例の多くは他の方法で書くことができると今でも感じています。これにより、表現できない表現力が言語に追加されることはありません。当初は十分な例で動機付けられると感じていましたが、この機能を使用できる例が多ければ@withoutboatsに同意するようになります。

（また、注目に値する：@nrcのクレートproc-macro-rules使用label_break_value 、それを避けるために書き直されているようです。）

1つのオプションは、上記のように現在のrfcbotルールを解釈して、「チェックボックスがないことはあなたの意見の相違を示します。過半数を却下するには3人のメンバーが必要です」という意味ですが、ルールが導入されたときの意味はそうは思わないので、この手順に従うべきだと提案するのは私にとって不誠実だったと思います（私は他の場所でそれを自分で行いましたが）。

私はそれが「棄権」のための正しい手順だと思いますが、反対するためではありません。

IMOは、それが最良/唯一のオプションであるさまざまな例を通してその重みを引き出すだけでなく、言語は実際には追加によって単純になります（他のラベル付き構造を許可することを考えると、ラベル付きブロックを許可しないことは私にとって驚くべきことです）。

私は通常、直交性の議論に説得力があると思いますが、個人的には言語でループブレークにラベルを付けたくないので、これは特に説得力がないと思います。

成長を続けるチームでは、機能についてコンセンサスを得ることができなくなり、特にlang-designチームでは、一貫した方法で言語を操作することが難しくなるのではないかと心配しています。

ステアリングだけでなく、停止も気になります。プロセスが「はい」へのパスを見つけることに焦点を合わせているように見え、フローチャートに「いいえ」につながるグラフエッジがなく、単に「まだ」ではない場合に発生する特定の必然性があります。

2018年と2019年には、言語の機能の成長について多くの投稿がありました。言語チームでは、言語の総表面積を真剣に検討する必要があると感じています。そして、私たちにはそれを奨励する良いプロセスがないように感じます。

joshtriplett 2019年01月08日

👎1

@joshtriplett

これにより、表現できない表現力が言語に追加されることはありません。

非常に明確にするために：それはまさにこれを行います。現在、他の制御フロー構造に干渉しないこのコードを表現する方法はありません。これは、（他の人が指摘しているように）マクロで特に望ましいものです。マクロでは、これがラベルのないブレークを介してターゲットにできない唯一の構造になります。マクロ作成者が、ユーザー提供のbreakと重複するリスクを冒すことなく、セクションから抜けることができます。

cramertj 2019年01月08日

👍8

また、ジグザグ（ラベルがまったくない場合-Luaの例を参照）やループで奇妙なことをする必要がないため、コードが読みやすくなります。これには、llvmがジグザグコードを最適化できるはずの場合でも、パフォーマンス上のわずかな利点があります。

SoniEx2 2019年01月08日

@joshtriplett

私はまだ、例の多くが他の方法で書かれている可能性があると感じています。これにより、表現できない表現力が言語に追加されることはありません。当初は十分な例で動機付けられると感じていましたが、この機能を使用できる例が多ければ多いほど、この機能を言語に取り入れるべきではないという

それはおそらく私たちが掘り下げることができるものですか？

私は通常、直交性の議論に説得力があると思いますが、個人的には言語でループブレークにラベルを付けたくないので、これは特に説得力がないと思います。

この一連の推論は奇妙だと思います（エディションでラベル付きのループブレークを削除したい場合を除く）。あなたが言語になかったと思ったことに基づいて設計上の決定を下すのは適切ではないようです。それはそこにあるので、この追加がそれと首尾一貫しているかどうかを検討する必要があります。そうでなければ、Rustについて私が違ったやり方でやったかもしれない多くのことがありますが、私はすべきではなく、できません。

ステアリングだけでなく、_停止_についても心配しています。プロセスが「はい」へのパスを見つけることに焦点を合わせているように見え、フローチャートに「いいえ」につながるグラフエッジがなく、単に「まだ」ではない場合に発生する特定の必然性があります。

はいなしでは安定しないという意味で、それ自体の「いいえ」の形はまだありません。さらに、いいえがあります。LBVは悪い考えである/ X、Y、およびZの理由で十分に動機付けられていないことを残りの人に納得させてください。そのような具体的な議論はまだ聞いたことがありません。また、ここでは必然性がないことを明確に示しています。

2018年と2019年には、言語の機能の成長について多くの投稿がありました。言語チームでは、言語の総表面積を「真剣に」考慮する必要があると感じています。そして、私たちにはそれを奨励する良いプロセスがないように感じます。

私は個人的にこれらの記事の多くは約いずれかであることを感じて、持続可能性（@nikomatsakisがやったとしてではなくとして適切な表現ではない...）またはその多くの人々は、言語チームがどのように動作するかを理解していない（私たちはすでに合計に真剣な検討を与えない、すなわち、表面積）。 Rustの全体的な表面構文は、おそらく実際には昨年に縮小し、成長していません。 LBVはそれを特に増加させることはなく、実際に言語のプロダクションの数を減らし、構文をより均一にするという議論をすることができます。

Centril 2019年01月08日

👍2

文法の生成を組み合わせるだけでは、言語の表面積は縮小されませ

rpjohnst 2019年01月08日

取ることができる条件付き分岐の数を減らすことは、間違いなく言語の表面積を縮小することです。

この特定の機能はどちらの方向にも進むとは思わないので、おそらく中立です。しかし、たとえば、言語構造を統合するもの（bool let、誰か？）は、表面積を縮小します。

SoniEx2 2019年01月08日

価値のあることとして、Common Lispは、マクロを備えたマルチパラダイム言語であるという意味でRustに似ており、この機能（ block / return-fromという名前）を備えています。ここで説明したのと同様に、Common Lispでは、この構造は、マクロを記述したり、還元不可能なほど複雑な制御フローを表現したりする場合に役立つことがよくあります。

(block foo
  (return-from foo "value"))

私の感覚では、CommonLispではこの機能は成功したと見なされています。言語の学習や実装を困難にする機能についての会話では出てきません。

traviscross 2019年01月12日

包含があります

early return from block ⊂ exceptions ⊂ call/cc

たとえば、Schemeでは、次のreturn-fromエミュレーションが実行可能です。

(define call/cc call-with-current-continuation)

(define-syntax block
    (syntax-rules ()
        ((_ label statements ...)
            (call/cc (lambda (label) (begin statements ...))))))

(block foo
    (display "Visible text")
    (foo "value")
    (display "Phantom text"))

スキームでは、 call/ccは物議を醸すほど成功していると見なされています。これについて話すことができるようにするには、最初にオブジェクトを作成する必要があるため、これは特に興味深いと思います。 call/ccを誤った機能と見なしても、知的意味で言語がより実質的になりました。

JohnBSmith 2019年01月12日

Nemerle言語にはNamedブロック機能があります。
とても便利で便利です。

return、break、continueは

NN--- 2019年03月03日

👍1

@jhprattこの号の議論を読んでください。

Centril 2019年07月28日

@Centrilの提案で私がIRLOについて行ったいくつかのコメントを繰り返し

この機能について説明する際に、次のインスピレーションを提案しました（通常のループ関連バージョンとは異なります）。

とにかく、ループはここでの私のインスピレーションではありません。 tryブロックを見ると、「クロージャーを作成する手間をかけずに、早期に戻る短いローカル計算を記述できると便利だと思います」。 tryブロックは、かなり制約のある「impl Tryを返したい」で機能し、どのような種類のラベルもサポートしていません。

上記は、このための私の主なユースケースです。私はアーリーリターンスタイルが好きです。 try {}ブロックはほとんどの場合そこに到達しますが、ここでも、ラベルを実際にはサポートしていません（ネストされたブロックにはtry {}?を記述するため、必要ではありません）。タイプをキャッチオールではない特定のモナディック形状に靴べらします（提供されているユースケースで証明されています）。

また、C ++についていくつかの観察を行いました。ここでは、特にRustのようなイテレータがない場合に、ラベルの中断/継続がないことが非常に苦痛です。たとえば、UB gotoまたはローカルbreak加えて、内側ループの外側に条件付きcontinueなければ、内側ループから外側ループを継続する方法はありません。

少なくともC ++にはボローチェッカーがないため、インラインラムダトリックの苦痛は少なくなります。これは、インラインラムダに戻るとLLVMのインラインラーによってLVBのようなものに変換されるため、効果的にLVBをサポートします。このようなものは... Rustではかなり疑わしいです。

また、この機能は、Goのgotoとほぼ同等の表現力を備えていることも指摘しておく必要があります。これは、コンパイル時に宣言などを飛び越えないようにするものです（率直に言って、Rob Pikeがgotoを受け入れられると考えた場合、 C ++の問題を打ち負かそうとした歴史、私は彼をある程度信頼します）。

我々は、従来技術に入るつもりならまた、Kotlinはまたの形で、この正確な機能を提供しますreturn<strong i="24">@label</strong> expr; 。

mcy 2019年08月26日

👍2

c'ish言語では、デバッガーがbreak function:label認識できるため、ループの下の安定したブレークポイントの場所として、着信gotoがなくてもラベルを使用することがよくあります。
休憩についてのコンセンサスがなくても、ラベルはいいかもしれません。

編集：1つの潜在的なハードルは、通常、ラベルがシンボルの命名規則に従うことです。RFCを理解している場合、これらのラベルはシンボルの命名規則に従わず、 'はシンボル名では無効です。
Dwarfや、gdb自体に問題があるかどうかはわかりませんが、実際にここに問題があります。

Edit2：
通常のcベースのラベルの引用動作を見ると、これには多少の煙があることは間違いありません。
デバッガーでは、gdbは少なくとも、シンボル名の一部ではなく引用符として引用符を処理します。次の結果は

0x401114のブレークポイント1：ファイル、ライン1。
比類のない見積もり

echo "void main() { } void hmm() { umm: return; }" | gcc -g -x c -;
gdb -ex "b hmm:'umm'" -ex "b hmm:'umm" -batch ./a.out

そして、この引用は記号の一致の前に行われると私は信じているので、これがgdbでのrust言語固有のサポートの影響を受ける可能性はないと思います。

編集：既存のループラベルのため、船はおそらくこれで航海しました。

ratmice 2019年08月26日

ブロックからの早期復帰を支持するマイナーなポイントは、貧乏人の契約プログラミングです。事前条件と事後条件としてassertステートメントを追加するだけです。快適さを維持するために、 returnをbreak 'retに置き換えて、次の構成を可能にする必要があります。

let value = 'ret: {
    // ...
};
assert!(postcondition(value));
return value;

ただし、これは不完全な解決策です。ブロック内でreturnを禁止する必要があるためです。

JohnBSmith 2019年11月22日

この機能が欲しかったのですが、存在することを知らなかったので使用しなかったというメモを追加します。これは、「使用する人が少ないことからわかるように、人々はそれを望まない」という否定的な修正だと思います。

私は今朝、IRLOのコンセプトを独自に

passcod 2020年04月11日

👍2

私は今日これで遊んでいます、そしてそれはasyncブロックで_超_便利になります。ただし、 try_blocks機能と組み合わせると、問題が発生するようです。

#![feature(try_blocks, label_break_value)]

fn main() {
    let _: Result<(), ()> = try {
        'foo: {
            Err(())?;
            break 'foo;
        }
    };
}

error[E0695]: unlabeled `break` inside of a labeled block
 --> src/main.rs:6:20
  |
6 |             Err(())?;
  |                    ^ `break` statements that would diverge to or through a labeled block need to bear a label

error: aborting due to previous error

jonhoo 2020年05月22日

トライブロックは間違いです。

... ?自体にラベルを付けることはできませんか？（ Err(()) 'foo?; ）

SoniEx2 2020年05月22日

トライブロックが間違いであることに強く反対しますが、それは別の議論であり、おそらくここで行ったり来たりする価値はありません。

この特定の例では実行可能かもしれませんが、 'fooにまともなコードのチャンクといくつかの?が含まれている実際のコードと比較すると、これは非常に最小限に抑えられています。

jonhoo 2020年05月22日

@ SoniEx2

トライブロックは間違いです。

このコメントは不適切です。 @jonhooのコメントは、（おそらく）バグのある相互作用を報告していました。 tryブロック（またはlabel-break-value）についての意見に関係なく、それらがスムーズに相互運用する必要があることは明らかです。

nikomatsakis 2020年05月22日

❤6

Err(()) 'foo?;構文を使用する必要があります。

SoniEx2 2020年05月22日

@jonhoo tryがどのように脱糖されるかという点で、implの詳細が漏れているのを見ていると思います。それを別の問題として提出して、可能な修正の議論をそこに移すことができますか？

nikomatsakis 2020年05月22日

👍1

RFCはそれを言います

'BLOCK_LABEL: { EXPR }

のシンタックスシュガーです

'BLOCK_LABEL: loop { break { EXPR } }

私はその置換を試みました、そしてコードは到達不能コードについての警告とともにコンパイルされます。

#![feature(try_blocks, label_break_value)]

fn main() {
    let _: Result<(), ()> = try {
        'foo: loop {
            break {
                Err(())?;
                break 'foo;
            }
        }
    };
}

ciphergoth 2020年05月22日

@ nikomatsakis @ ciphergothはhttps://github.com/rust-lang/rust/issues/72483として提出されました

jonhoo 2020年05月23日

私はもはやこれに反対していません。今日検討されていれば、ラベル付きブレークの最初の概念にもっと強く反対したでしょうが、その概念が存在することを考えると、任意のブロックへの適用に反対し続けることは意味がないと思います。

（これは、 breakを使用する現在のフォームに適用され、他の構文には適用されません。）

@rfcbot resolve should-close-not-merge
@rfcbotレビュー

joshtriplett 2020年05月23日

🎉3

@joshtriplettこれは「早期返品」を行う唯一の方法であるため、 asyncブロックで非常に役立つことがわかりました。これは、書く代わりに次のことを意味します。

async {
  // do thing a
  if thing_a_failed {
    // handle specially (note, _not_ ?)
  } else {
    // do thing b
    if thing_b_failed {
      // handle specially (note, _not_ ?)
    } else {
      // do thing c, etc..
    }
  }
}

私は書くことができます：

async {
  'block {
  // do thing a
  if thing_a_failed {
    // handle specially (note, _not_ ?)
    break 'block;
  }

  // do thing b
  if thing_b_failed {
    // handle specially (note, _not_ ?)
    break 'block;
  }

  // do thing c, etc..
  }
}

これは、ときれいに似てどのようにすることができますと早期復帰returnの関数/、として閉鎖continue/breakループインチ確かに、余分なブロックが必要なければいいのですが（ async 'block {の可能性はありますか？）、ネストされたif-sよりも間違いなく勝っています。

jonhoo 2020年05月23日

👍4

非同期ブロックにラベルで直接注釈を付けることができるようにすることは、この機能の非常に優れた拡張機能のように思えます。

retep998 2020年05月23日

👍6

@rfcbotfcpキャンセル

FCPは永久にブロックされているため、ここでキャンセルします。おそらく、この未来を推し進めたいかどうかについて話し合う必要があります。他に何もないとしても、非同期ブロックを考慮に入れるように更新する必要があるようです。これにより、この機能の新しいユースケースが追加されるようです。

nikomatsakis 2020年06月16日

👍1

@nikomatsakisの提案はキャンセルされました。

rfcbot 2020年06月16日

非同期ブロックが存在する場合、この提案のセマンティクスについてあいまいさがないことに注意してください。RFCの定義は引き続き適用されます。

'BLOCK_LABEL: { EXPR }

のための単なる構文糖です

'BLOCK_LABEL: loop { break { EXPR } }

ただし、暗黙のループにバインドされるラベルのないブレークまたはコンティニューは、EXPR内で禁止されています。

ciphergoth 2020年06月16日

breakのラベルを付ける代わりに、非同期ブロックから（早期に） returnを使用できることに注意してください。したがって、非同期ブロックにラベルを付けることはあまり意味がありません。

let fut = async {
    return 42;
    0
};

println!("{}", fut.await); // prints 42

（遊び場）

WaffleLapkin 2020年08月21日

@WaffleLapkin私は最近ここに来て、でそのことをに気づきました。この機能は、コードのセクションを_スキップ_できるようにするためにまだ非常に便利だと思います（このブロックの残りの部分を実行しないでください。また、戻らないでください）が、 async _特に_への適用性は以下です。私は最初に思った。

jonhoo 2020年08月21日

👍1

Rust: RFC 2046、label-break-valueの追跡の問題

最も参考になるコメント

全てのコメント135件

安定化提案

報告する

FCP前のTODO

関連する問題