Rust: 删除三元运算符

我同意。 我想知道为什么我们也有三元运算符。

同意。 希望我让 JS 成为一种表达语言。 伟大的语句/表达式拆分激发了 ?: 但 Rust 没有这一点，并且 if-else 就足够了。

/是

作为 C/C++ 中 ?: 运算符的重度用户，我更喜欢紧凑的语法。 我还认为，当表达式太长而无法放在一行中时，它的格式会更好：

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不能放在一行中，语法会变得更糟。 例如，大括号应该放在哪里。

只有我的两分钱。

我喜欢：

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

它添加了一些额外的行（“else 行”和最后的括号），但它保持干净，您可以添加任意数量的代码。

我在 C++ 中经常使用三元运算符，但我认为语法很差。 你必须发现？ 和 : 在其他标记的海洋中，可以看到它甚至是一个条件。 使用表达式 - 如果您有向读者指示“这里有条件”的前导标记。

好吧，我仍然更喜欢?:运算符的语法。 我发现您选择的格式过于冗长，特别是对于if_true和if_false是单个表达式的简单情况（与以表达式结尾的多个语句相反）。

尽管如此，如果删除 ?: 运算符，我不会强烈反对。

我也在到处使用?: ，但我仍然认为删除它是个好主意——它在我们的表达式语法中释放了两个 (!) ASCII 符号。 想想我们可以用它们做的所有其他非常神秘的事情。

一个非神秘的用途是允许它们作为谓词名称的一部分。
例如“空？()”而不是“is_empty()”。

@marijnh ++ :)

就个人而言，我不屑一顾。 伊戈尔在https://mail.mozilla.org/pipermail/rust-dev/2010-November/000110.html 中为三元辩解

这是在 pull req #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 用户编写不必要的繁重/冗长的代码，因为这种常见的做法（三元运算符）存在于大多数（如果不是所有）语言中。

无论如何，它已经完成了，但我只是想为那些支持更简洁代码风格的人添加我的声音。

我也想念这个语法

我认为这里有三个合谋的影响，即

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 }

或我个人最喜欢的“拥抱条款”之一

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)

看看那个……你有选择……因为_一切_都是一个表达式。

我从来没有想过要保存写if {} else {}而不是的 _6 个字符_
() ? : ，加上链接额外的条件，使用 if-as-an-expression 看起来更好。 （嵌套的三元运算符很快就会变得混乱。）

在我看来：当使用if-as-an-expression我认为没有必要注入这么多不必要的空格。 我还发现它比三元运算符读起来更自然，额外的冗长有助于在视觉上将两个子句分开。 那只是我的$0.02

我想你可能误读了我说的话（并注意这是前一段时间）

我只是指出我没有看到三元运算符在任何方面看起来“无限好”。
在我看来，普通形式比特例形式要美得多。

评论是说有时，条件表达式非常有用，而不是条件语句。 放弃拥抱牙套只是主观上的改进

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

对比

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

@caitp是这里的第二个真的比第一个差无限吗？ Rust 的 if else 仍然是一个表达式（不是一个语句）。

我的想法是：

• 第二个似乎对没有其他语言历史的人来说更具可读性，并且
• 我们可能会更好地保留?语法以备将来使用（可能与 Option 等相关）

@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); }

我认为我们真正需要意识到的是，这个问题已经存在三年多了。 考虑到人们在三年内并没有真正错过那么多三元组，我认为可以肯定地说他们会被移除。

@caitp嗯，我仍然不确定我是否在关注。 您是在特别谈论生锈吗？ 或者只是一般的语句与表达式？

在 Rust 中你仍然可以做

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

? （顺便说一句，我知道你不是在谈论大括号，抱歉造成混乱：smile_cat:)

当时，在 ToT 中，Rust 没有办法做到这一点。

我没有强烈的意见，但我只想补充一点，如果?和:可以更好地用于其他事情，为什么不使用像??和?:代替，例如cond ?? 43 ?: 0 ？

为什么要改变开发人员已经习惯了几十年的方式？

萨姆。 10 月 24 日 2015 02:46, Kevin Atkinson [email protected] a
评论：

我没有强烈的意见，但我只想补充一点？ 并且可以
最好用于其他感谢为什么不使用类似 ?? 和 ？：
反而。 所以也许条件？ 43 ?: 0。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/rust-lang/rust/issues/1698#issuecomment -150728625。

@RenaudParis对不起，我想说的是：我没有强烈的意见，但我只想补充一点，如果?和:可以更好地用于其他事情，为什么不使用??和?: ，例如cond ?? 43 ?: 0 ？

三元运算符被删除的原因之一是“？” 将来可以用于其他用途。 我的建议是使用另一个运营商。 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
 }