proposal: support int(bool) conversions in Go.1.5 (language change)

[alandonovan]

I propose the following language change for Go 1.5:

An explicit conversion int(b) where b has a boolean type would become legal, and would yield 1 if b is true, 0 otherwise.  Similar conversions would be legal for all numeric types.

Rationale: currently this function cannot be computed in a single expression, despite it being often useful, hard to misuse, efficiently implemented by modern ALUs, present in nearly all other languages, and syntactically natural in Go.

While I appreciate the value of avoiding implicit int/bool conversions, forbidding explicit ones seems slightly obtuse, and as a result of its omission, one must write four extra lines of code:

 var i int
 if b { 
     i = 1
 }
 ... i ...

which the gc compiler does not optimize this into the obvious single instruction.

The reverse operation bool(i), is not essential since i != 0 has the same effect and can be used in an expression context, but could be added for symmetry.  (I have no strong opinion.)

[emidoots]

I'm no such authority to say, but I think things like this are best discussed on the golang-nuts mailing list first. Most people don't review each Go issue, in contrast most do read the mailing list and could provide useful insight before such a change is made.

[ShawnMilo]

And on the list you'll be asked what problem this solves and how it solves it better than the existing method. And then they'll say that taking something completely unambiguous and impossible to misunderstand and adding the ability to do it in a redundant way which could be confusing and will cause bugs due to unintentional casting is not beneficial for the language. When it comes to Go, think minimalism.

If you have a use-case where your proposal is demonstrably better than the status quo, please provide it in the list for discussion, because without it the conversation will be a non-starter.

[minux]

I hate to say, but this has been proposed and rejected.

We should teach gc to generate better code, instead of adding features to
the language.

And yes, this should be discussed on golang-nuts first.

[griesemer]

1. It shouldn't be too hard for a compiler to recognize

i := 0
if b {
   i = 1
}

and create the respective single instruction (or conditional bit set, depending on what happens with i, etc.)

2. It's trivial to define e.g.

func bool2int(b bool) int {
   if b {
      return 1
   }
   return 0
} 

where needed.

3. Together with 1), the bool2int function should become trivial code-wise and then should be inlineable, effectively giving you int(b).

4. There may still be merit in conversions of bools to numeric values, but using a helper function for now should get you almost all the way there. The rest is optimization.

[alandonovan]

On 17 December 2014 at 14:38, Robert Griesemer notifications@github.com
wrote:

1. It shouldn't be too hard for a compiler to recognize

i := 0
if b {
i = 1
}

and create the respective single instruction (or conditional bit set,
depending on what happens with i, etc.)

2. It's trivial to define e.g.

func bool2int(b bool) int {
if b {
return 1
}
return 0
}

where needed.

3. Together with 1), the bool2int function should become trivial code-wise
   and then should be inlineable, effectively giving you int(b).

4. There may still be merit in conversions of bools to numeric values, but
   using a helper function for now should get you almost all the way there.
   The rest is optimization.

The question is: would you prefer to read just this "int(x.f > 0)", or four
lines of statements inconveniently breaking up a long expression?
My assertion is that the status quo is both less readable and less
efficient.

[minux]

i think bool2int(x.f > 0) is just as readable.
if we really need to change the language, ternary operator is more general than this proposal,
and it's also trivial for the compiler to turn that into a conditional select instruction.
(I'm not proposing ternary operators... it's too ugly when nested.)

[mattn]

FYI: https://groups.google.com/d/msg/golang-nuts/w1dPeHFSp9g/cMjgL76B7jIJ

[cookieo9]

In my experience the most beneficial of this feature would be as follows:

var check bool = something
// ...
value := requiredValue + int(check) * optionalValue

IE: only add optionalValue if check is true.

This would normally be expressed in go as:

var check bool = something
// ...
value := requiredValue
if check {
    value += optionalValue
}

In this situation I would argue that the later is more clear about what is happening. Also, the former would most likely require a multiplication instead the conditional branch. Only in the case where optionalValue == 1 or -1 (ie: add or subtract 1 if boolean is set) could the multiplication be easily avoided.

If it is the case that

value := required + int(check)

would produce better code than

value := required
if check {
    value++
}

then the optimizer should be improved. IMHO the latter is still clearer about what is happening, albeit not as much as the original example.

Also, the former would most likely require a multiplication instead the conditional branch.
Only in the case where optionalValue == 1 or -1 (ie: add or subtract 1 if boolean is set)
could the multiplication be easily avoided.

It's been a couple of decades since a paid attention to CPU architecture, but at that time conditional branching was significantly more expensive than multiplication. Have things changed that much?

[minux]

I think this is a dup of #6011.

[011010101101]

@serussell No, branching is still more expensive. Modern CPUs have to guess which way a branch is going to go. If they guess wrong, they will realize much later that they have to go back and redo a lot of prior computation. That is very slow: something like 20 instructions wasted on a modern Intel CPU. See https://en.wikipedia.org/wiki/Branch_predictor

For speed, then, it would be better for the compilers to avoid conditional jumps for bool-to-int conversion.