proposal: math: add Bool(bool) int

[jimmyfrasche]

Helper to convert boolean expressions to numeric types under the standard false = 0, true = 1 mapping.

package math
func Bool[T number](v bool) T {
  if v {
    return 1
  }
  return 0
}

where number is replaced by the constraint for all numeric types, wherever that ends up and whatever it ends up being named.

As inference improves, the type should need to be specified less often.

I don't think the name is too important at this point. The important parts are is this the right thing in the right place. Names can be discussed once those are decided.

A language change to allow direct conversion from a boolean expression to a numeric type has been rejected several times, #9367 and #45320 . This is the next best thing.

This has been forked from discussion in #61643.

[ianlancetaylor]

We can't infer the type argument, and I would imagine that int is a common case, so I think this ought to be

func Bool(v bool) int

That will save people from writing Bool[int](b); they will write Bool(b) instead. People who want a type other than int can write int64(Bool(b)), which is no worse than Bool[int64](b).

[atdiar]

Same reflexion as @ianlancetaylor and I also find the function name confusing.
No idea what could be better.
math.BtoI? math.BoolInt? Etc.

[jimmyfrasche]

@ianlancetaylor you're probably right but just because it's not inferred now doesn't mean it will never be inferred.

If inference is later changed so that the generic version could be used like

var x int64 = math.Bool(p)
n := x * math.Bool(q)

the non-generic version would still need to be used like

x := int64(math.Bool(p))
n := x * int64(math.Bool(q))

Even with maximal inference I imagine there would still be times where you'd need to write the type. This is most useful as part of another expression so I'd have to assume that there'd be enough type information the majority of the time in practice.

I wouldn't mind adding the type even if it's most often int but it would be nice to have to do it less and less as inference improves.

Even today I'm sure you could find cases where it would be handy to have the generic version like passing it to something like

func f[S, T any](x S, y T, f func(S) T) S

I'm not sure what the best long term decision is but I'd hate to sacrifice it to what's optimal now. That said, I'd be fine if it were int only. That would probably be good enough most of the time.

[atdiar]

@jimmyfrasche since it's a function call, the general handling of inference would require interprocedural analyses (the inferred type can depend on the call site which can be found at an arbitrary depth)

Even without that, I'm not sure inference will work for every calls.

I'd tend to think that int would suffice.

[jimmyfrasche]

@atdiar consider the example of n * math.Bool(q) the information available in that expression is

• n has known type T0
• * needs both of its arguments to be the same type
• math.Bool[T1](q) has unknown type T1

From that we can conclude that T0 = T1 for the program to be well typed.

Whether that can be computed efficiently and whether it gets implemented are different questions but it's not anything fancy.

Certainly that doesn't mean every case imaginable could be inferred but my assertion is that most calls would be within an arithmetic expression so if those are supported that should cover a lot of the uses.

[atdiar]

@jimmyfrasche

I see what you mean. But then for comparisons,

if math.Bool(p) < math.Bool(q){...}

Wouldn't work, no?

(*using the math.Bool name although I still think that it is confusing since it doesn't return a boolean)

[earthboundkid]

Maybe strconv.Btoi makes more sense than math.Bool. If it were strconv.Btoi() string with outputs "0" and "1", you could still compare the strings with cmp.Compare.

[earthboundkid]

The other idea is to have package bools, something like

func Int(bool) int // 0 or 1
func Compare(bool, bool) int
func Xor(bool, bool) bool
func Xnor(bool, bool) bool

[jimmyfrasche]

the name: unimportant for now. No point in finding the perfect name if it doesn't happen. It's a placeholder. Feel free to continue to discuss it but I am purposefully ignoring my impulse to engage for now.

@atdiar you are correct that would always require a type to be specified for at least one of the calls.

@carlmjohnson:

re strconv.Btoi() string comparison isn't the only use case. A more important one is using it as an https://en.wikipedia.org/wiki/Iverson_bracket

A package is interesting. It could contain Int and a generic version, for that matter. Maybe Any and All as well. I like that idea.

[earthboundkid]

Maybe func Any(...bool) bool and AnyFunc[T any](func(T) bool, ...bool) bool, plus All/AllFunc. Could also be called "Some" and "Every".