Elixir似乎每个操作都有2个布尔运算符：
|| , or
&& , and
等。唯一的区别是对于or, and等，第一个参数本身必须是一个布尔值。当|| , &&等似乎能够处理所有事情时，这些第二组算子的重点是什么？
答案 0 :(得分：7)
根据Basic Operators上的Elixir教程：
or和and是短路运营商。他们只执行权利 如果左侧不足以确定结果
要回答您的问题，第二组运算符的重点是什么？;我认为教程非常好。
根据经验，当您期待时，请使用
and，or和not布尔值。如果任何参数不是布尔值，请使用&&，||和!。
我的选择
&&和and示例
iex(1)> nil && 13
nil
iex(2)> true && 17
17
iex(3)> true and true
true
iex(4)> false and true
false
iex(5)> 73 and false
** (ArgumentError) argument error: 73
答案 1 :(得分：6)
好的，直接来自Elixir所有事物的真相来源：
两个主要原因：
- 编写断言代码：如果您期望布尔值，请使用布尔值
- 卫兵是严格的布尔，所以你必须在那里使用“和”和“或”
直接来自Jose Valim。
另外，彼得·汉密尔顿（信用证到期的信用证）指出了Erlang创作者之一Robert Virding的启发性信息：
关于布尔运算符的一些历史和一些哲学 和警卫。
很久以前我们明确决定使用布尔运算符'和'，'或'， 'xor'和'not'并没有真正的价值观。这不是因为我们 我不熟悉真正的逻辑，我们是长期的C 和lisp程序员，我们只觉得它更合乎逻辑（哈哈）。这些 最初都是严格的，只接受布尔参数。后来 出现了对短路'和'和'或'的渴望。代替 重新定义'和'和'或'我们添加了新的运营商'和'也'和 '要不然'。最初这些也是（bool，bool）和 orelse（bool，bool）因此将测试第二个的价值 论点。这后来改变了，所以第二个参数不是 检查，由于其他原因，这是在其他原因 语言和由于尾调用优化的可能性。一世 我个人从来没有使用过它。
我个人并不是真正的操作员的粉丝，并认为'零'闻起来 在其他语言中有点像null。
关于警卫。最初他们是守护测试并且被认为是 模式的扩展与不能很好的事物匹配 写成一种模式。测试成功或失败。 IMAO这个 使警卫的内容和处理更加一致 失败/异常，这只是一次失败的测试。什么时候允许 守卫变得复杂，他们徘徊成为守卫表达 返回布尔值，然后整个守卫成为一个 布尔表达式。我认为这使得解释起来更加困难 为什么警卫的外表和行为就像他们一样。
我将此答案标记为社区维基，因为它本身并不是我的答案。
答案 2 :(得分：5)
对我来说，当你不想将任何其他值（或数据类型）解释为true时，想要将布尔值作为第一个参数可能会有所帮助，因为除了nil和false之外，elixir将采用任何真值。用户可能希望确保参数是布尔值（true或false），而不是意外地除了任何其他类型的值。
或，和， 等布尔运算符期望true或false作为第一个参数
轻松的布尔运算符，如 || ，＆amp;＆amp; ，！可以采用任何类型的参数。除nil或false之外的任何值都被解释为true（真实）。
例如
x || y # gives x if x is truthy else y
x && y # gives y if x is truthy else x
!x # false if x is truthy , otherwise true
如果您尝试
iex(5)> not 3
** (ArgumentError) argument error
:erlang.not(3)
iex(6)> ! 3
false
答案 3 :(得分：0)
根据我的理解，有关Elixir中＆amp;＆amp; 和 || 的一些值得注意的事项
这有助于证明在Elixir中0是true
iex(1)> (0 && true) and true
true
但以下情况并不奏效：
iex(2)> (true && 0) and true
** (ArgumentError) argument error: 0
因为在这种情况下，Elixir尝试评估0 and true：在Elixir中 true 需要布尔值。
这是因为0是true && 0表达式的最后一个值（似乎是真的！）