关于Go创作者为什么不把‘not’当作‘`false`’的历史参考

Question

为什么Go创建者选择不将nil视为false？为什么他们认为显式地将值与nil进行比较更好呢？有可靠的消息来源可以解释为什么会这样吗？他们的意见是什么？这个决定背后的逻辑是什么？

我在找历史的参考资料。

例如：

f, err := os.Open(name)
if err != nil {
    return err
}

而不是像在许多其他语言中那样，将nil隐式转换为false：

f, err := os.Open(name)
if err {
    return err
}

从现在起，后者将提供：

non-bool err (type error) used as if condition

Answer 1

有些语言做到了这一点，并造成了太多的问题。这主要是违反了最不惊讶的原则。其中一些问题是：

• 所有非零值都将评估为true。指向false布尔值的指针将计算为true。所有这些都会产生新的、更大的复杂问题，也就是更多的bug。
• 将布尔值分配给nil将是有效的。将布尔值与nil进行比较将是有效的。这会造成语义混乱。更多的虫子。
• 代码将更难阅读，因为它隐藏了意图。如果您想检查布尔值或断言其他类型的变量的“非nilness”，则不可能从表达式中分辨出来。更多的虫子。
• 在表达式中的比较操作中省略的操作数会编译得很好，从而使识别bug变得更加困难。考虑一下if a == '3' && b { .. }这样的情况，您忘记了添加比较，所以b总是计算为true，即使这不是您想要的。越来越多的虫子。

去吧，人们可能会考虑到这一点，而更倾向于使用更少bug的代码更好。

可以有一个快捷方式，只是将错误传播给调用方，例如：

require f := os.Open(name)
// if the call returns error, return error 

编辑:我很高兴地报告Go团队正在考虑在Go 2中使用与我的建议非常相似的方法。只是他们使用了关键字check：

check f := os.Open(name)
// if the call returns error run the declared error handler 
// which in turn, can return the error or do something else about it.

Answer 2

虽然我在任何关于golang文档或开发人员的讨论中都找不到确切的原因，但最接近的原因仅仅是没有值(nil)不应该被解释为false。这也符合这样一个事实: golang是一种非常固执己见的语言，它的作者认为，在评估真假时不使用类型会提高代码的质量。