language: bool to numeric and numeric to bool type conversions

[tildeleb]

Overview
This proposal would allow bidirectional type conversions between all of the builtin
scalar numeric types and the builtin "bool" type. The syntax and grammar of
the language already allows these conversions but the current compiler doesn't implement
these particular conversions and gives error messages. As has been standard since
"C" was developed the numeric value of 0 is considered "false" and
any non-zero numeric value is considered "true", but the canonical value of
"true" is numeric 1.

Description
Today if you want to convert between a numeric type and the "bool" type you
have to create a function to do it. For example:
http://play.golang.org/p/jUlDoCCI5N

var itob = func(int i) bool {
    if i == 0 {
        return false
    }
    return true
}

var btoi = func(bool b) int {
    if b {
        return 1
    }
    return 0
}

These functions also define the semantics I propose for the conversions proposed.

Because there are currently no generic functions and no trinary operator one often has
to implement multiple versions of the above functions.

If this proposal is accepted and implemented the following two conversions and others
like them would no longer generate the following compiler errors in the cg compilers:

var i int= 1
b := bool(i)
i := int(b)

./bool.go:24: cannot convert i (type int) to type bool
./bool.go:25: cannot convert b (type bool) to type int

Justification
After several years of Go programming I long for this functionality. I often need to
convert a slice of numbers to bools or bools to numbers in a loop. Having to call a user
defined function for each conversion is slow and in many (all) cases these conversions
can be handled without branches and in any case these conversions can and should be
inlined.

Implementation
The implementation requires that the compilers be updated to allow these conversions and
generate code for each case. The scalar numeric types affected are:
uint8, uint16, uint32, uint64, int8, int16, int32, int64, float32, float64, uint, int,
byte, rune

Since I have seen integers passed as a uintptr using OpenGL via Cgo I suggest that the
type "uintptr" also be allowed as a numeric type that can be converted to and
from a "bool".

Documentation
In the "Conversions" section of the "The Go Programming Language
Specification" the following line would change from:
"x's type and T are both integer or floating point types.""
to:
"x's type and T are both integer, floating point, or bool types."

Issues
I am unsure of how to handle floating point +0.0 and -0.0. Right now I think only
regular 0.0 is "false" but I am unsure about this.

Related Issues
https://golang.org/issue/6011
This is similar to #6011 except the proposed syntax is different. I believe the syntax
proposed here is more consistent with the spirit of the language and is simpler too.
Importantly, I would like to point out that the Type Assertion syntax isn't needed here
because any numeric value can be converted to a "bool" and any
"bool" can be converted to a numeric value so these conversions can never fail.

[adg]

Comment 1:

> Today if you want to convert between a numeric type and the "bool" type you have to
create a function to do it.
You can convert between any numeric type and bool with the expression "n != 0".
(That one fewer character than the proposed "bool(n)".)
You say "I often need to convert a slice of numbers to bools or bools to numbers in a
loop." Can you please provide a concrete example?

[ianlancetaylor]

Comment 2:

Labels changed: added repo-main, languagechange, release-none.

[tildeleb]

Comment 3:

The code that converts between the slices/arrays of bools and ints is closed source.
Sorry about that. I can work something up if you want but the last time I did this for
an issue, everyone complained that my simplified example was too simplistic.
I know about "n != 0" and I should have addressed that in the proposal. The simple
answer is that when you are converting a type to a different type it should be very
clear that you are doing that. In my opinion "bool(n)" makes it very clear. Recognizing
"n != 0" is idiomatic. The fact the it's one less character is largely irrelevant.

[cznic]

Comment 4:

Using m[v] and v != 0 to convert from/to bool is easy and I see no problem with it. IMO
definitely not worth a language change.

[tildeleb]

Comment 5:

I assume for m[v] you mean a map to convert from bools to a number? That's clever. I
hadn't done that myself because I hoped the compiler would inline the function I made to
do it and perhaps get rid of the branches as well.
1. This is going to boil down to how people feel about "idiomatic" vs "standard" type
conversions. If you are OK with these particular conversions being idiomatic and don't
mind sprinkling map or function declartions throughout your code to convert bools to
numbers then this change isn't for you.
2. If on the other hand you've ever wanted to do a bool/numeric conversion and felt that
the code should *read like a conversion*, then this change is for you.
3. I want to point out that this isn't really much of a language change, it's more of
relaxation of the current compiler implementations. The language already accepts the
construct from a syntax/grammar standpoint. The current versions just disallows these
particular conversions. As language changes go, this is about as small a language change
as is possible. As noted above, the language change is documented by adding "or bool
types" to a single sentence of the reference spec.

[cznic]

Comment 6:

Ad "*read like a conversion*". That's IMO a non goal. Math has no (well defined) mapping
between booleans and numbers - that's why it's a mess in some languages.
Code, on the other side, can produce different numbers conditionally, where the
condition is a boolean.
IOW, it should look like code, not like a conversion which it isn't.

[griesemer]

Comment 7:

Status changed to Duplicate.

Merged into issue #6011.