proposal: spec: support int(bool) conversions #64825

adonovan · 2023-12-20T22:04:52Z

Proposal Details

I propose, a second time, the following language change first proposed for go1.5 in #9367:

An explicit conversion int(b), where b has a boolean type and int stands for any integral type, would become legal and would yield 1 if b is true, 0 otherwise.

Rationale: currently this function cannot be computed in a single expression, despite it being often useful, hard to misuse, present in nearly all other languages, and syntactically natural in Go. As a corollary, there is currently no simple way to derive an integer constant from a boolean constant.

While I appreciate the value of avoiding implicit int-to-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 ...

Also, consider implementations of sort.Interface.Less that define a total order over tuples. They consist of a sequence of operations, one per column (x, etc) of the tuple, of this form:

if a[i].x != a[j].x {
    return a[i].x < a[j].x
}

For booleans, the < operator must be expressed as the opaque !a[i].x && a[j].x. It would be easier to read int(a[i].x) < int(a[j].x).

The motive here is brevity and clarity, not efficiency. I am confident that a good compiler can avoid the branch. The concern with efficiency in the previous proposal was a distraction, and it has been dealt with separately.

We do not propose to support the reverse operation, bool(i), as one can already say i != 0 in expression context (and it's shorter). Also, i != 0 makes the semantics explicit, where bool(i) could potentially be misinterpreted as i > 0, i == 1, i == max[u]int, i == -1, or i & 1 == 1, all of which are representations of "true" used in other languages; and George Boole would have argued that the bool(int) function is simply not defined for values other than zero and one.

We also do not propose to support float64(b) and complex128(b). Though consistent, there is little need for such conversions, and they can easily be implemented in two steps, still within expression context, for example float64(int(b)).

In https://go.dev/cl/550235, I measured the occurrence of code snippets like the one above. Across about 19,000 modules, there are about 10K places where an if/else statement is used to simulate an int(bool) conversion. (I didn't attempt to find places where if/else was used to compute bool < bool, as is common in sort.Interface.Less implementations.) Of those, I ignored the ~5.5K in generated .pb.go files, and the ~2K in copies of github.com/wzzhu/tensor, leaving about 2700 more interesting cases. Here's a random sample of a few dozen:

And here are all occurrences in the standard library:

src/runtime/proc.go:5422:2: [if]: run0 = int(!iscgo && cgoHasExtraM && extraMLength.Load() > 0)
src/runtime/symtab.go:1062:2: [if]: mask = int(off == ^uint32(0))
src/reflect/abi.go:380:3: [if]: x = int(b.Get(i))
src/time/format.go:417:2: [if]: n = int(u == 0)
src/compress/flate/huffman_bit_writer.go:405:2: [if]: flag = int(isEof)
src/encoding/binary/binary.go:348:4: [if-else]: bs[0] = int(*v)
src/encoding/binary/binary.go:354:4: [if-else]: bs[0] = int(v)
src/encoding/binary/binary.go:361:5: [if-else]: bs[i] = int(x)
src/encoding/binary/binary.go:546:2: [if-else]: e.buf[e.offset] = int(x)
src/math/big/float.go:1377:2: [if]: sbit = int(len(r) > 0)
src/math/big/nat.go:235:3: [if-else]: c = int(cx < c2 || cy < c3)
src/crypto/x509/pkcs1.go:108:2: [if]: version = int(len(key.Primes) > 2)
src/internal/zstd/zstd.go:210:2: [if-else]: windowDescriptorSize = int(singleSegment)
src/go/printer/nodes.go:619:5: [if]: min = int(prev != nil && name == prev)
src/go/types/mono.go:198:3: [if]: weight = int(typ == targ)
src/internal/pkgbits/encoder.go:275:2: [if]: x = int(b)
src/compress/flate/deflate_test.go:180:3: [if-else]: b[i] = int(r.cur+int64(i) >= r.l-1<<16)
src/go/scanner/scanner_test.go:735:2: [if]: cnt = int(err != "")
src/go/types/hilbert_test.go:153:4: [if]: v = int(i == j)
src/strings/builder_test.go:105:3: [if]: wantAllocs = int(growLen == 0)
src/unicode/utf8/utf8_test.go:168:3: [if]: wantsize = int(wantsize >= len(b))

The text was updated successfully, but these errors were encountered:

zephyrtronium · 2023-12-20T22:25:35Z

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.

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.

jimmyfrasche · 2023-12-20T22:33:33Z

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.

zephyrtronium · 2023-12-20T22:34:31Z

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?

fzipp · 2023-12-21T05:24:36Z

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

adonovan · 2023-12-21T14:34:34Z

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

cespare · 2024-01-05T19:35:51Z

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.)

earthboundkid · 2024-01-09T04:20:52Z

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. 😆

rsc · 2024-02-01T20:24:16Z

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

soypat · 2024-02-03T14:07:39Z

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

var a int = x > y || b

fzipp · 2024-02-03T14:09:42Z

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

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

or

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

rsc · 2024-02-14T18:28:39Z

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.

thepudds · 2024-02-14T18:38:11Z

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).

randall77 · 2024-02-14T18:39:13Z

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.

cespare · 2024-02-14T18:57:35Z

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?)

jimmyfrasche · 2024-02-14T20:04:26Z

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.

rsc · 2024-03-01T17:44:22Z

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

mvdan · 2024-03-01T17:56:05Z

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.

earthboundkid · 2024-03-01T18:12:57Z

I filed an alternative proposal: #66062.

mvdan · 2024-03-02T17:45:06Z

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).

jdemeyer · 2024-03-03T14:29:44Z

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.

gh2o · 2024-03-06T15:22:55Z

@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.

zephyrtronium · 2024-03-06T17:01:53Z

@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.

gh2o · 2024-03-06T17:10:38Z

@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.

rsc · 2024-03-06T18:17:12Z

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.

aclements · 2024-03-06T18:18:09Z

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).

rsc · 2024-03-08T04:00:39Z

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

adonovan · 2024-03-09T19:25:30Z

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

mdempsky · 2024-03-19T18:29:37Z

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)?

soypat · 2024-03-19T19:38:29Z

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.

adonovan · 2024-03-19T19:56:29Z

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!

mdempsky · 2024-03-19T20:33:32Z

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.

andig · 2024-03-21T20:34:47Z

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?

earthboundkid · 2024-03-21T21:07:06Z

And much less bool(int).

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

rsc · 2024-03-27T18:17:44Z

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).

adonovan · 2024-06-14T20:34:40Z

Composing int(bool) with strings.Repeat gives you optional strings, still in expression context, and without allocating:

fmt.Printf("%s.(%s).%s",     // e.g. "bytes.(*Buffer).WriteString"
  packageName,
  strings.Repeat("*", int(isPtr)), // optional *
  typeName,
  methodName)

vituchon · 2024-07-12T22:41:03Z

Too much talk... let's implement this feature already! I mean.. I do never get a technical reason for not doing this... you may peek at the summary I have made regarding the state of this, here.

zigo101 · 2024-07-14T16:27:39Z

You can use nstd.Btoi at the time, though it has not the type inference convenience.

PeterHindes · 2024-08-27T04:50:53Z

I am in support of this. This missing feature is the one reason I would still use c.

adonovan · 2024-08-27T13:56:54Z

This missing feature is the one reason I would still use c.

While I appreciate the vote of support for this late proposal, I question the wisdom of your choices. ;-)

adonovan added the Proposal label Dec 20, 2023

adonovan added this to Proposals Dec 20, 2023

adonovan moved this to Incoming in Proposals Dec 20, 2023

gopherbot added this to the Proposal milestone Dec 20, 2023

adonovan mentioned this issue Dec 20, 2023

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

Closed

seankhliao changed the title ~~proposal: support int(bool) conversions~~ proposal: spec: support int(bool) conversions Dec 26, 2023

earthboundkid mentioned this issue Jan 9, 2024

Split truthy into sub-packages earthboundkid/truthy#2

Closed

seankhliao added the LanguageChange Suggested changes to the Go language label Jan 13, 2024

ALTree mentioned this issue Jan 25, 2024

proposal: unsafe: add a func to convert bool type to int #65274

Closed

rsc moved this from Incoming to Active in Proposals Feb 1, 2024

rsc moved this from Active to Likely Decline in Proposals Mar 1, 2024

rsc added the Proposal-FinalCommentPeriod label Mar 1, 2024

earthboundkid mentioned this issue Mar 1, 2024

proposal: cmp: Add Cond[T any](cond bool, ifval, elseval T) T #66062

Open

rsc moved this from Likely Decline to Declined in Proposals Mar 8, 2024

rsc closed this as completed Mar 8, 2024

rsc removed the Proposal-FinalCommentPeriod label Mar 8, 2024

thanm mentioned this issue Mar 20, 2024

Go compiler and runtime meeting notes #43930

Open

golang locked as resolved and limited conversation to collaborators Aug 27, 2024

proposal: spec: support int(bool) conversions #64825

proposal: spec: support int(bool) conversions #64825

Comments

adonovan commented Dec 20, 2023 • edited Loading

Proposal Details

zephyrtronium commented Dec 20, 2023 • edited Loading

jimmyfrasche commented Dec 20, 2023

zephyrtronium commented Dec 20, 2023

fzipp commented Dec 21, 2023 • edited Loading

adonovan commented Dec 21, 2023 • edited Loading

cespare commented Jan 5, 2024

earthboundkid commented Jan 9, 2024

rsc commented Feb 1, 2024

soypat commented Feb 3, 2024 • edited Loading

fzipp commented Feb 3, 2024

rsc commented Feb 14, 2024

thepudds commented Feb 14, 2024

randall77 commented Feb 14, 2024

cespare commented Feb 14, 2024

jimmyfrasche commented Feb 14, 2024

rsc commented Mar 1, 2024

mvdan commented Mar 1, 2024 • edited Loading

earthboundkid commented Mar 1, 2024

mvdan commented Mar 2, 2024

jdemeyer commented Mar 3, 2024

gh2o commented Mar 6, 2024

zephyrtronium commented Mar 6, 2024

gh2o commented Mar 6, 2024 • edited Loading

rsc commented Mar 6, 2024

aclements commented Mar 6, 2024

rsc commented Mar 8, 2024

adonovan commented Mar 9, 2024

mdempsky commented Mar 19, 2024

soypat commented Mar 19, 2024

adonovan commented Mar 19, 2024 • edited Loading

mdempsky commented Mar 19, 2024 • edited Loading

andig commented Mar 21, 2024 • edited Loading

earthboundkid commented Mar 21, 2024

rsc commented Mar 27, 2024

adonovan commented Jun 14, 2024 • edited Loading

vituchon commented Jul 12, 2024 • edited Loading

zigo101 commented Jul 14, 2024

PeterHindes commented Aug 27, 2024

adonovan commented Aug 27, 2024

adonovan commented Dec 20, 2023 •

edited

Loading

zephyrtronium commented Dec 20, 2023 •

edited

Loading

fzipp commented Dec 21, 2023 •

edited

Loading

adonovan commented Dec 21, 2023 •

edited

Loading

soypat commented Feb 3, 2024 •

edited

Loading

mvdan commented Mar 1, 2024 •

edited

Loading

gh2o commented Mar 6, 2024 •

edited

Loading

adonovan commented Mar 19, 2024 •

edited

Loading

mdempsky commented Mar 19, 2024 •

edited

Loading

andig commented Mar 21, 2024 •

edited

Loading

adonovan commented Jun 14, 2024 •

edited

Loading

vituchon commented Jul 12, 2024 •

edited

Loading