Rust: 三項演算子を削除します

同意します。 なぜ三項演算子もあるのだろうと思っていました。

同意しました。 JSを表現言語にしたかったのに。 素晴らしいステートメント/式の分割は？：を動機付けますが、Rustにはそれがなく、if-elseで十分です。

/なれ

C / C ++の？：演算子の非常にヘビーなユーザーとして、私はコンパクトな構文を好みます。 また、式が長すぎて1行に収まらない場合は、フォーマットが適切になると思います。

let x = some_very_long_condational
     ? if_true
     : if_false

let x = if some_very_long_condational 
     { if_true}
     else { if_false}

私の見解では、 if_trueとif_falseが1行に収まらない場合、構文が悪化する可能性があります。 たとえば、中括弧はどこに配置する必要があります。

ちょうど私の2セント。

好き：

let x = if some_very_long_condational { 
                 if_true
           } else { 
                 if_false
           }

いくつかの余分な行（「else行」と最後のブラケット）が追加されますが、クリーンに保たれ、どちらにも必要な数のコードを追加できます。

私はC ++で三項演算子をよく使用しますが、構文が貧弱だと思います。 あなたは？ および：他のトークンの海の真ん中で、それが条件付きであることを確認します。 式付き-読者に「条件付き」を示す先頭のトークンがある場合。

それでも私は?:演算子の構文を好みます。 特にif_trueとif_falseが単一の式である単純な場合（式で終わる複数のステートメントとは対照的に）、フォーマットの選択が冗長すぎると思います。

それでも、？：演算子が削除された場合、私はあまり強く反対しません。

私もあちこちで?:を使用していますが、それでも削除するのは良い考えだと思います。式の構文で2つの（！）ASCIIシジルが解放されます。 私たちがそれらを使ってできる他のすべての驚くほど不可解なことを考えてください。

不可解な使用法は、述語名の一部としてそれらを許可することです。
たとえば、「is_empty（）」の代わりに「empty？（）」を使用します。

@marijnh ++ :)

個人的に私は愚痴を言うことはありません。 Igorはhttps://mail.mozilla.org/pipermail/rust-dev/2010-November/000110.htmlで三項を主張しました

これはプルリクエスト＃1705で行われました。

    return parent.index_of(child_a) < offset_b ? -1 : 1

よりも無限に良く見えます

    return if parent.index_of(child_a) < offset_b {
        -1 
    } else {
        1
    }

私たちがこれについてパイソンである必要がある場合は、

return -1 if parent.index_of(child_a) < offset_b else 1

はるかに良いでしょう。

私は同意します、なぜそれを削除しなければならなかったのか分かりません...そのような一般的な慣習（三項演算子）がすべてではないにしてもほとんどの言語に存在する場合、Rustユーザーに不必要に重い/冗長なコードを書かせないでください。

とにかく、それは完了しましたが、私はよりクリーンなコードスタイルをサポートする人々に私の声を加えたかっただけです。

私もこの構文が恋しい

ここでは、3つの共謀効果が働いていると思います。

1）「素晴らしいステートメント/表現の分割」（@BrendanEich）;
2）ブールコンテキストでの非ブールの強制。
3）最近では、「動的」言語でさえ、「動的構文」（実際のマクロ）や「動的セマンティクス」（Pythonのfrom __future__ import division ）を取得することは一般的ではありません。

（1）は、 if ... then ... else ...が... ? ... : ...とは根本的に異なることを意味します。これは、完全に不要な区別です。 returnようなエッジケースがありますが、全体的に区別する必要はありません。

（2）は、多くの言語で、テストとして任意の式を使用できることを意味します。 これは、あなたがまだあなたの第一言語を使用している限り便利に見え、あなたがあなたの第二言語から始めるとすぐに迷惑になります。 このredditの議論で上で指摘したfalseまたはtrueいずれかを示す必要がある理由は明確ではありません。 if ( d.length == 0 ) ...と書くだけで、非常に明確になります。

（3）は、言語委員会から提供されたものに固執していることを意味します。つまり、誰かがコードベースをフォークまたは書き換えて新しい名前を付けるまで、言語は固執する可能性があります。 異なる可能性があります。 たとえば、 use 'ternary conditions'; use 'empty lists are false';を許可する言語が存在する可能性があります。 その前例があります。 もちろん、これらの「偏差マーカー」を常に念頭に置き、プログラムをコピーアンドペーストするときにそれらをコピーすることを忘れないようにする必要があるため、多くのことがそのような柔軟性に反対します。 OTOHは、単なるユーザーが言語の構文とセマンティクスを簡単に変更し、そのようなプラクティスをインストール可能なモジュールに事前にパッケージ化できれば、言語の進化に大いに役立つ可能性があります。

@kevina冗長性が悪いことではない場合もありますが、三項演算子がコードを非常にうまくクリーンアップすることに同意します。

@caitp ：正確には何が問題になっていますか？

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

または私の個人的なお気に入りの「ハグ条項」の1つ

return 
    if parent.index_of(child_a) < offset_b { -1 } 
    else                                   {  1 }

...または、特に複数の条件がある場合は、一致を使用します...

return match parent.index_of(child_a) < offset_by {
  true  => -1,
  false => 1
}

...そしてもちろん、再利用される可能性が高い場合：関数に移動するだけです...

return parent.is_child_before(offset_b)

それを見てください...あなたには選択肢があります..._ everything_は式だからです。

さびたことがないので、 if {} else {}代わりに
() ? :に加えて、追加の条件を連鎖させると、if-as-an-expressionの方がはるかに見栄えがします。 （ネストされた三項演算子はすぐに乱雑になります。）

私の意見では、 if-as-an-expressionを使用する場合、不要な空白をそれほど多く挿入する必要はないと思います。 また、三項演算子よりも自然に読み取れ、追加の冗長性が2つの句を視覚的に分離するのに役立ちます。 それは私の$0.02

あなたは私が言ったことを読み間違えたかもしれないと思います（そしてこれは少し前だったことに注意してください）

三項演算子が「無限に良く」見える方法がわからないことを指摘しているだけです。
私の意見では、一般的なフォームは、特殊なケースのフォームよりも無限に美しいです。

コメントは、条件文とは対照的に、式としての条件が非常に役立つ場合があると言っています。 抱き締めるブレースを落とすことは主観的にのみ改善です

return parent.index_of(child_a) < offset_b ? -1 : 1

vs

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

@caitpはここで2番目です本当に最初よりも無限に悪いですか？ Rustは、elseがまだ式（ステートメントではない）である場合です。

私の考えは次のとおりです。

• 2つ目は、他の言語の履歴がなくても読みやすいようです。
• 将来の砂糖（おそらくオプションなどに関連する）の​​ために、 ?構文を維持したほうがよいでしょう。

@mitchmindtree完全に。

繰り返しますが、あなたはコメントが言っていたことを誤解しています。

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }はまだ条件を式として評価しています（したがって、 returnオペランドになることができます）。

中括弧は醜いですが、要点は中括弧ではなく条件式に関するものです。 return foo.bar.baz(<conditional operand>)対if (<conditional operand>) { return foo.bar.baz(1); } else { return foo.bar.baz(2); }を書くことができるということです

私たちが本当に認識しなければならないのは、この問題は3年以上前のものだということだと思います。 3年間でそれほど多くのターナリーを見逃していないことを考えると、彼らは削除されたままであると言っても過言ではありません。

@caitphmm私がフォローしているのかまだ

さびであなたはまだすることができます

return foo.bar.baz(if cond { 42 } else { 0 })

？ （中かっこについて話していなかったことは承知しています。混乱してすみません：smile_cat :)

当時、ToTではRustでこれを行う方法はありませんでした。

強い意見はありませんが、 ?と:を他の用途に使用したほうがよい場合は、 ??ようなものを使用してみませんか。代わりに?: 、たとえばcond ?? 43 ?: 0 ？

なぜ開発者が何十年も慣れている方法を変えるのですか？

ルサム。 10月24日 2015年2時46分、ケビン・アトキンソン[email protected] A
écrit：

強い意見はありませんが、付け加えたいのですが？ および：できます
どうしてこんなものを使ってみませんか？ と ？：
代わりは。 だから多分条件?? 43？：0。

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

申し訳ありません@RenaudParis、私が言うために意図していた：私は強い意見を持っていないが、私はちょうど追加したいという場合は?と:良く、他のもの、なぜに使用することができます代わりに??や?:ようなものを使用しないでください。たとえば、 cond ?? 43 ?: 0 ？

三項演算子が削除された理由の1つは、「？」 将来、他の何かに使用される可能性があります。 私の提案は、別の演算子を使用することでした。 cond ?? 43 ?: 0はまだif cond {43} else {0}よりも短いです。

削除するのは正しいと思いますが、単一の表現にブレーサーが必要ない場合はそれほど悪くはありません。 （そして、はい、これがパーサーにどれほどの痛みがあるかを知っています。それはそれだけの価値があります-読みやすさは非常に重要です）

例えば

if i ==0 
     return i
else 
      1  

あるいは

if i == 0  return i
    else 1  

このフォーマットはより良いです

 if i == 0   ? return i
      : 1  

また

if i == 0   
      ? return i 
      : 1  

詩

if i ==0 {
      return i
}
else {
    1
}      

かなり醜い/とても一般的な何かのために読むのは難しい。

エジプトの中かっこに対する開発ポリシーがあると、悪化しますが読みやすくなります。

if i ==0
{
     return i
}
else
{
     1
 }