关于Go创作者为何选择不将“ nil”视为“ false”的历史参考[关闭]

Question

Why did Go creators choose to not treat nil as false? What why did they think it is better to explicitly compare values to nil? Is there a reliable source that would explain why is that is Go? What was their opinion? What was the logic behind this decision?

I'm looking for a historical reference.

---

E.g.:

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

Than to implicitly cast nils to false like in many other languages:

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

As of now, the latter would give:

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

Answer 1

Some languages did that and it caused too many problems. It's primarily a violation of principle of least surprise. Some of the problems are:

• All non-nil values would evaluate to true. A pointer to false boolean value would evaluate to true. All of that would create new and larger set of complications, aka more bugs.
• Assigning a boolean to nil would be valid. Comparing a boolean to nil would be valid. That creates a semantic confusion. More bugs.
• Code would be harder to read because it hides the intent. It's impossible to tell from an expression if you want to check a boolean's value or assert "non-nilness" of some other type of variable. More bugs.
• Omitted operands in comparison operations in expressions would compile fine, making identifying bugs harder. Think about if a == '3' && b { .. } kind of cases where you forget to add the comparison so b always evaluates to true even if it's not what you intend. More and more bugs.

Go people probably thought about it and preferred code with less bugs is better.

There could be a shortcut though just to propagate the error to the caller such as:

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

EDIT: I'm happy to report that Go team adopted a very similar approach to what I suggested, in Go 2. Only they used the keyword check instead:

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.