See also #45320, #63544.

Worth noting that in addition to the list of examples above, there are a number of constants especially in the compiler and runtime defined as both Booleans and integers for the purpose of feature detection in different contexts; see e.g.

Since converting a constant to a type that is not a type parameter type results in a constant, this change would allow the integer versions to go away. That's an important feature of a language change over e.g. #61915.

In the analysis the if/if-else and return are two different species. if/if-else is the use of an int(bool) conversion and return is the definition of an int(bool) converter which was, presumably defined so as to be used more than once. A second pass would be needed to find the invocations of these converters to compare with the if/if-else usages. Possibly not worth doing but important to consider when evaluating the results.

The proposal mentions that float64 and complex128 not supported, but what about other integer types? Are int32(x != 0) and uintptr(x != 0) considered, or is it sufficient to always convert through int?

I don't know about uintptr, but I think supporting other integers like uint32 would be beneficial. I have use for this in a CPU emulator:

https://github.com/fzipp/oberon/blob/ebf0a23b7c5422dda878336f07d5c4b31c1919d8/risc/risc.go#L245-L248

https://github.com/fzipp/oberon/blob/ebf0a23b7c5422dda878336f07d5c4b31c1919d8/risc/risc.go#L623

In response to #64825 (comment), I updated the proposal to clarify that it includes all integer types.

The proposal text mentions writing a "less" comparison func for bools, but does not mention the increasingly-common "cmp" comparison functions (used by slices.SortFunc, slices.BinarySearchFunc, and so on). That is where I most miss an int(bool) conversion.

(Related to the declined proposal #61643.)

With this you could write

func Compare(x, y int) int {
  return int(x > y) - int(x < y)
}

I don't know if that's good or bad. 😆

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Would supporting the bool->int conversion mean the following is valid?

var a int = x > y || b

No, it's an explicit conversion. It would be either

var a int = int(x > y || b)

or

a := int(x > y || b)

Every language change carries significant constant costs to update everything - tools, books, docs, etc - and the data (2,700 potential non-machine-generated uses in 19,000 modules) seems to show that this would be used about 0.2 times per module, which doesn't seem worth it.

Assuming this gets declined, then in a separate issue, we may still want to make sure the compiler will handle code like this correctly:

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

That way people can still write their own version and know it will be handled properly.

I think that particular form is not compiled today as efficiently as it could be, but if you write it instead as:

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

...then it compiles down to MOVBLZX on amd64 (Godbolt link).

It is already basically handled properly.
At every callsite of bool2int, it is inlined and uses the right instructions - a single sign-extend.
bool2int by itself does not use the right instructions, but that's probably not a real issue. No one is going to be calling this indirectly.

As this proposal states, discussion of efficiency here is a distraction, just as it was a distraction in #9367.

This is purely about writing clear and concise code.

Right now, it's annoying to deal with bools when writing some kinds of expressions, particularly comparisons, in a way that dealing with other basic data types like integers and strings is not. This is particularly true for the func(X, X) int ("cmp") functions that are becoming common in the standard library as of the last few releases, and which are not yet broadly reflected in the existing corpus of code.

I'm sure that if we look, we can find plenty of language changes that will be used by less than 20% of modules. (Not to mention existing language features. What percentage of modules use complex types?)

As remarked in #61915 (comment) and this thread, one of the things that cannot be done now is use of bool→int in constants. That requires a language change.

I would also like to reiterate that the analysis undercounts in multiple ways so the numbers provided are a floor. I'm also not sure why we're not counting machine generated modules. Use in machine generated code should be weighted less, sure, but not discarded. It's still evidence of real-world use.

I'm also not sure use-per-module is the right proxy. I've written modules that don't use floating point numbers that doesn't make them less useful.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Personally I'd be sad if we punt on this addition once again. I very much relate to Alan's original points that it feels like an omission in the language that makes it somewhat inconsistent. I've had to write this function five times in the past handful of years, which is certainly not often, but each time I'm left with the impression that it's a silly situation to be in.

In that way, I see this proposal as being very similar to min and max - we could have declined that proposal using very similar arguments, but having the built-ins makes some Go code easier to write and maintain. I was lukewarm on the proposal when it was first opened, but now that I have the builtins, I definitely wouldn't give them up.

It's true that every language change carries its cost, but in this case, I honestly feel like the cost is tiny. We should weigh quality of life improvements for human developers in the long term over minimal tooling pain in the short term, I think.

I filed an alternative proposal: #66062.

One thought I had: if the solution being a language change is what is keeping this proposal from being a net positive, we could always consider a builtin function like func oneif(b bool) int. That is the name I've personally chosen in the past for explicitness; bool2int as a name would feel like a weird way to sidestep bool(int).

The fact that this has been requested so many times by different people seems to indicate that there is a need here. It's a simple and obvious feature request, I don't understand the resistance against it.

@zephyrtronium

Worth noting that in addition to the list of examples above, there are a number of constants especially in the compiler and runtime defined as both Booleans and integers for the purpose of feature detection in different contexts; see e.g.

go/src/internal/goexperiment/exp_arenas_on.go

Lines 7 to 8 in adec22b

	const Arenas = true
	const ArenasInt = 1

Since converting a constant to a type that is not a type parameter type results in a constant, this change would allow the integer versions to go away. That's an important feature of a language change over e.g. #61915.

I agree with this 100%: currently it's possible to convert 0/1 to false/true via x != 0 in a constant expression, but it has always bothered me that there is no way to convert false/true to 0/1 in the same way. Often times I've had to resort to keeping all of my consts as ints to make them usable in constant expression calculations when it makes much more sense for them to be bools.

@gh2o

Often times I've had to resort to keeping all of my consts as ints to make them usable in constant expression calculations when it makes much more sense for them to be bools.

It may be helpful if you can share places you've done that. Examples of people actually needing int(bool) conversions in a capacity that a function cannot replace is probably the most important kind of information for the proposal process.

@zephyrtronium

One example I found in the go codebase itself: if these files were not auto-generated, I think it does make more sense for these values to be bools instead of ints from a type correctness standpoint.

Decline doesn't mean that it will never happen, just that it won't happen now. We have limited time, and as more and more things build on Go, every change becomes more difficult to make, because it requires updating everything above it in the stack.

I'm sure approximately nothing uses complex types. If Go didn't have them today, I think we would decline adding them pretty quickly. It was much easier to add things back then. The bar is always moving up, for better or worse.

Another example from the Go tree: https://github.com/golang/go/blob/go1.22.1/src/internal/goexperiment/exp_allocheaders_on.go Having written a fair amount of code using the GOOS and GOEXPERIMENT int constants, I agree it's very annoying. :)

Are there examples not from the Go tree itself? This pattern is unfortunately not captured by the ecosystem analysis (and I'm not sure how you'd do it reliably).

No change in consensus, so declined.
— rsc for the proposal review group

The analyzer I used is at https://go.dev/cl/550235, where it will remain in deep cryostorage until needed again.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group

I'm surprised by these assessments by the proposal review group. The discussion here seems overwhelmingly in favor of adding these conversions. E.g., there are as many thumb-up "votes" on this issue already as there were on #59488, which added the min and max builtins.

Proposal #46505 to allow ArrayType(sliceValue) conversions as shorthand for *(*ArrayType)(sliceValue) (a much smaller and more niche convenience than this proposal) had fewer thumbs ups. I pointed out the same hesitation around tooling impacts (#46505 (comment)) and again (#46505 (comment)), yet the proposal group accepted that.

@ianlancetaylor argued:

That is true, of course, but the resulting code seems to me to be clearer and more straightforward. Why not take the minor win?

Doesn't this argument hold even more strongly for allowing users to write func() IntType { if boolExpr { return 1 }; return 0 }() as IntType(boolExpr) than it did for allowing *(*ArrayType)(sliceExpr) as ArrayType(sliceExpr)?

Worth mentioning there are many more examples under the b2i name out in the wild than those mentioned. This pattern is especially present in embedded systems programming. Here are more examples under the b2u8 name, mostly belonging to the embedded ecosystem of Go.

Worth mentioning there are many more examples under the b2i name out in the wild than those mentioned. This pattern is especially present in embedded systems programming. Here are more examples under the b2u8 name, mostly belonging to the embedded ecosystem of Go.

Don't forget to enable the "Exclude Go vendor" filter in the left pane.

BTW this is my favorite of all of them, which uses "unsafe" to make it faster. The difference is "almost unnoticeable", but every picosecond counts!

BTW this is my favorite of all of them, which uses "unsafe" to make it faster. The difference is "almost unnoticeable", but every picosecond counts!

I wish GitHub offered "☠️" as a reaction.

Based on the discussion above, this proposal seems like a likely decline.

Funny that happend after two encouraging comments by well-known gophers. Really sad the Go team played this as it is.

The discussion here seems overwhelmingly in favor of adding these conversions.

That's exactly how I read the discussion.

Now I'm stuck with being able to do string([]byte) but not int(bool). And much less bool(int).

We have limited time, and as more and more things build on Go, every change becomes more difficult to make, because it requires updating everything above it in the stack.

Given that it would be great if the community could weigh in in prioritising changes instead of just singular yes/no votes?

And much less bool(int).

That's trivially i != 0. There's not a lot of point in adding it except symmetry.

There is no denying this would occasionally be useful. The problem is balancing overall churn against that utility. If someone is very excited about this change, the usual way to make the case (or not) would be to prepare a small stack of CLs showing (1) the spec changes, (2) the compiler and go/types changes, and (3) updating all the code in the main repo to use it as effectively as possible. (1) and (2) show that there is not too much involved (although there is always more to do in programs like staticcheck and gopls), and (3) demonstrates the benefits. I am still skeptical that the benefits will be large enough, but we definitely missed the ones @aclements pointed out in package runtime, of not having to maintain pairs of aligned constants. We can just emit the booleans and convert them in constant expressions as needed. Maybe there are others we missed too. The diffs for (3) are what matter most: demonstrate benefits justifying the cost in (1) and (2).