阻止一元`&`的优先级

Question

考虑以下 Ruby 代码：

[1,3].any? &:even? || true
# => false
[1,3].any? &nil || :even?
# => false
[1,3].any? &nil || :odd?
# => true

因此，Boolean-or || 似乎比 to-proc 一元 & 具有更高的优先级。我没想到会这样。是这样吗？它是否记录在任何地方？

Answer 1

这就是（被错误地诽谤的）and 和 or 关键字的用途。你应该把它写成

[1,3].any? &:even? or true

至于为什么会发生这种情况——我找不到这方面的文档——但我认为它实际上更多地与可选括号和一元 & 的限制有关。

一元 & 是特殊的。像~ 这样的“普通”运算符本质上是方法调用的语法糖；你可以把它们放在你想要的任何地方。但是&只允许在方法参数中，即使这样也只能在最后。

foo x, &bar
# NameError, determined at runtime because it has to see if any of these names are defined
foo &bar, x
# SyntaxError! Didn't even make it past the parser

y = bar
# NameError
y = &bar
# SyntaxError!

当你在方法调用中去掉括号时，它会吞掉几乎所有的东西，只在 if/unless/and/or 等超低优先级的东西上停止。

foo bar baz if true
# same as
foo(bar(baz)) if true

所以你的例子相当于

[1,3].any?(&:even? || true)

现在，如果& 在某种程度上具有高优先级，这要么是在运行时评估的完全正常值true，要么是高度受限的特殊语法构造&:even?。在运行时发现语法错误并不是很好，所以我猜开发人员选择了一种简单的方法来解决它：使& 超低优先级。这样解析器可以只验证语法规则并忽略块参数本身（必须在运行时评估）。

Answer 2

当& 前面没有一个对象（一元）并且紧随其后的是其他任何东西（在这种情况下为&nil）。它将被解析为尝试的to_proc 方法调用，否则它将被视为接收方的方法调用，例如

 nil&nil
 #=> false  

相当于nil.&(nil)

所以在你的情况下（[1,3].any? &nil || :even?）它被解析为[1,3].any?(&(nil || :even?))，因为&（to_proc方法调用）的优先级低于逻辑||，并且需要知道nil || :even?的结果继续。

但是，可操作的 and (&) 需要一个接收器（不是一元的），但确实比逻辑 or (||) 具有更高的优先级，例如[1,3].any? &nil&nil || :even? 将评估为

[1,3].any?(&(nil.&(nil) || :even?)
#=> false
# Or
[1,3].any?(&(nil & nil || :even?)
#=> false

奇怪的是，显然操作和 (&) 的优先级高于逻辑或 (||)

更多例子

true & nil || :even? 
#=> :even?

true & :even? 
#=> true

[1,3].any? &true&true || :even?
#=> TypeError: wrong argument type TrueClass (expected Proc)

# Okay no problem

class TrueClass
  def to_proc
    ->(*_) { true } 
  end
end 

[1,3].any? &true&true || :even?
#=> true
[1,3].any? &true || :even?
#=> true

更奇怪的是，一元 & 允许 nil 但基本上从 block_given? 中忽略它，但任何其他未实现 to_proc 的对象都会引发 TypeError

def no_block
  block_given? ? yield('Yes') : 'No'
end

no_block &nil
#=> "No"

no_block &false
#=> TypeError: wrong argument type FalseClass (expected Proc)