Proposal: remove @boolToInt in favor of @bitCast

[wooster0]

As @ifreund pointed out in #7950, @bitCast can serve the function of @boolToInt just fine: #7950 (comment):

const std = @import("std");

pub fn main() void {
    std.debug.print("{}\n", .{@bitCast(u1, true)}); // 1
    std.debug.print("{}\n", .{@bitCast(u1, false)}); // 0
}

The purpose of @boolToInt is to serve as a branchless alternative to if (x) 1 else 0 because in that case you have to depend on the optimizer to not emit a branch.

Advantages

• Language simplification and easier implementation
• One less way to do something; @bitCast(u1, x) already works
• One less thing to keep in your head if you keep the builtins in your head
• You always know what you get: a u1, whereas with @boolToInt currently you can get u1 or comptime_int
• Logical and straightforward
• Encourages the use of @bitCast for doing other things the smart way, too
• Don't make a simple boolean to integer conversion seem special; it's not. It's one of many other things @bitCast can do easily.

Disadvantages

• Non-existence of the specialized @boolToInt might make it harder to remember that you should use @bitCast/@boolToInt instead of if (x) 1 else 0. But one could argue if you don't keep all builtins in your head this doesn't matter anyway.
  If we wanted to remind people we could even add a little note to the docs of @bitCast in the langref but ultimately this is just one of many things that are expected to work with @bitCast so I wouldn't even say this is noteworthy. So, this point can basically be disregarded.
• 2 more characters and 1 more keystroke:

  @bitCast(u1, x) // 19 keystrokes
  @boolToInt(x)   // 18 keystrokes

If, like the other @*to* builtins, @boolToInt provided additional safety I would understand its existence but as it stands it doesn't really provide anything that @bitCast doesn't.

[Jarred-Sumner]

I wish it would expand the size if you add two together when the destination type is a larger size.

This code panics:

pub export var counter: usize = 0;
pub export var dynamic_bool: bool = true;

test {
    counter += @boolToInt(dynamic_bool) + @boolToInt(dynamic_bool);
}

Similarly, I wish it was @as instead of @bitCast or @boolToInt

[mlugg]

@Jarred-Sumner

I wish it would expand the size if you add two together when the destination type is a larger size.

That's essentially widening arithmetic, which is a completely separate proposal, unrelated to @boolToInt itself.

Similarly, I wish it was @as instead of @bitCast or @boolToInt

This would either a) break the very basic rule that @as is equivalent to implicit coercion or b) hugely weaken type safety around bools (which I doubt is something anyone wants). For clarity's sake, converting a bool to an int should not be an implicit operation.

[Jarred-Sumner]

@Jarred-Sumner

I wish it would expand the size if you add two together when the destination type is a larger size.

That's essentially widening arithmetic, which is a completely separate proposal, unrelated to @boolToInt itself.

Similarly, I wish it was @as instead of @bitCast or @boolToInt

This would either a) break the very basic rule that @as is equivalent to implicit coercion or b) hugely weaken type safety around bools (which I doubt is something anyone wants). For clarity's sake, converting a bool to an int should not be an implicit operation.

The status quo is that adding two runtime-known bool's will crash your program or cause undefined behavior. That is a footgun.

I'm not super opinionated about the solution, only that this is a small thing that makes it harder to write reliable software in Zig.

[tisonkun]

You always know what you get: a u1, whereas with @boolToInt currently you can get u1 or comptime_int

I'm working on #15701 so that @boolToInt always returns u1. This can be a pioneer step for this proposal (to ensure all usage of @boolToInt expect a u1, we found several issue in #15701).

BTW, to "simplify" the language means also we should clean up existing code dependency to @boolToInt.

To be clear, I'm +1 for this proposal as it works like a charm - I like it.

[recursivetree]

I'm not in favor of this, @boolToInt is way more descriptive of what it does than @bitCast. Additionally, is it guaranteed that a bool will always be represented as an integer internally? I haven't studied the wasm or spirv backend, but it wouldn't surprise me if they support bools natively rather than just bits

[andrewrk]

@bitCast from bool to u1 should indeed work.

However, remember that #5909 is also accepted, which means that @bitCast will lose its destination type parameter. This will make @boolToInt be more useful than @bitCast for bools for two reasons:

1. In the common situation that the destination type is a wider integer than 1-bit, @boolToInt would have the desired behavior, while @bitCast would be a compile error, or require @as(u1, @bitCast(b)) in order to be equivalent.
2. @boolToInt makes it become a compile error if the operand changes from bool to another type, whereas @bitCast would continue to convert between the types even though the operand is no longer a bool. Sometimes this is what you want, sometimes it's not. And that's why there are two ways to do it.

[Flecart]

Hello, I can't find the function @boolToInt anymore, has it been removed?

[Vexu]

It was renamed to @intFromBool.

[Flecart]

@Vexu thank you