"non-bool used as if condition" - why not?

[bcand...@googlemail.com]

I tried googling and searching the FAQ, but I didn't find the answer to this question.

Coming from a C background, I see a lot of Go code like this:

if err != nil {

    ...

}

And I wonder why the language designers decided not to allow this:

if err {

    ...

}

especially since Go has a well-defined notion of "zero value" which could be treated as "false" in this context.

Clearly it's a matter of design preference and idiom, and some languages have chosen the other path. Python has a similar concept of zero values (e.g. empty strings and empty arrays are false); Ruby treats all values as true, apart from false and nil.

I expect this has been discussed before, so happy to receive any pointers.

Thanks,

Brian.

[Jakob Borg]

On 20 May 2017, at 17:01, bcandler100 via golang-nuts <golan...@googlegroups.com> wrote:
>
> And I wonder why the language designers decided not to allow this:
>
> if err {
> ...
> }
>
> especially since Go has a well-defined notion of "zero value" which could be treated as "false" in this context.

Implicit type conversion is necessarily a thing in dynamically typed languages. Having empty dicts and so on be false can be convenient but also confusing. I assume you mean that a nil slice in Go would false, for example. Would the empty slice also be false? A zero length slice? A slice containing only zero values? A zero sync.Mutex or bytes.Buffer? Those are both usable in their zero state and having them be false would enable some really confusing antipatterns. I don't think we'd have to wait long for the first

If !mut {
mut.Lock()
}

to appear, for example.

//jb

[Rob Pike]

I have (schematically) seen this C++ code in production:

bool flag = "false";

This kind of problem is introduced by implicit type conversions, and (outside of some carefully controlled cases with interfaces), Go does not have them, for just this sort of reason. Bugs caused by implicit type conversions can be very hard to see.

-rob

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Tao]

On Sat, May 20, 2017 at 8:18 PM, bcandler100 via golang-nuts
<golan...@googlegroups.com> wrote:
> I expect this has been discussed before, so happy to receive any pointers.

Speaking of pointers... I've seen a serious, real world bug in C++
code that looked like this:

if (delete_the_users_data) {
delete_data(etc);
}

What was the bug? delete_the_users_data was a *bool, not a bool.

[C Banning]

Echoing Nigel. Here's some C:

if ((tempNode->parent) && (tempNode->arcToParent->flow))
{
   // do some work
}

Here's some Go:

if tempNode.parent != nil && tempNode.arcToParent.flow != 0 {
   // do some work
}

Certainly the Go code is easier to understand; especially if you're asked to support someone else's code.

Source: https://github.com/clbanning/pseudo.