长话短说，我正在编写一个包含options参数的方法，如果key:if的值计算为true，它将执行某些操作。当我使用新语法在IRB中尝试哈希时，在IRB中遇到语法错误，提示保持打开状态:
1.9.3p374 :010 > {if: true}
1.9.3p374 :011?>
使用旧语法，可以正常工作:
1.9.3p374 :011 > {:if => true}
=> {:if=>true}
所有开始语句的关键字都表现出相同的行为。例如。
def，do，module，case在中间和
class中出现的其他保留字也可以正常工作:else，end我的问题是:这是预期的行为，错误还是限制？
最佳答案
可靠且明确地解析任何语言的内容都是一项挑战。当您开始使用保留字时尤其如此。 irb必须超越此范围，并在解析器的顶部提供一个交互式模型，这更加困难。我个人认为，不管是作为语言的使用者还是维护者，担心这样的情况都没有太大的值(value)。在我看来，最好简单地找出可行的方法，并尽可能避免陷入这些情况。
您可以在irb之外的普通Ruby中看到一些类似的行为。例如:
puts({if: true}) # no problem, behaves as expected in Ruby 1.9.3.
puts {if: true} # raises a syntax error in Ruby 1.9.3
要回答您的问题，是“预期的行为，错误还是限制”，我想说您应该忽略
irb并将其与普通的Ruby进行比较，如果这样做，它可以很好地工作。这意味着它必须是irb错误。但是，有可能还是值得解决？ @coreyward在他的评论中很好地指出，在遇到
irb的大多数情况下，if必须延迟执行。您可能需要进一步了解才能确定，但是您可能无法明确地解释所有这样的情况。我的建议:如果可以，请完全避免使用此构造，如果可以避免，请不要在标签上使用保留字!
这是可以与普通Ruby(例如MRI)一起运行的文件。您应该在输出中看到
{:if=>true}，以确认它可以正常工作。{if: true}
foo = {if: true}
# if MRI is working, should be able to execute this file without trouble.
p foo
关于ruby - IRB-Ruby 1.9.x哈希语法: {if: true} is not equal to {:if => true}，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14966696/