I would like to add the possibility of adding, multiplying and subtracting bool from int that is, have implement with bool from int.
I might go further and do this for all strictly widening (same-signed?) numerical operations, but for better or worse in rust this is currently spelled
my_int + my_bool.into()
Possibly this is just a small ergonomics hit that is just waiting on some way to set inference defaults, possibly some believe this is the way things should be.
1 Like
While I generally wouldn't mind automatic integer widening, I personally like that Rust doesn't auto-convert bool to int. Strict typing has saved me from some (dumb) mistakes.
21 Likes
This idea presumes that true and false have integer meanings. The fact that C represents them as 1 an 0 may provide context but does not automatically provide this meaning. For example, why should 5 - true not be zero? (consider that in C five is also true) True and false do not inherently have integer value, they are from a different category.
This is especially obvious when considering true + true: should it be false (wrapping around in Z_2) or true (logical addition) or 2 (since true == 1)? (the last condition must hold under your proposal because 5 + true == 6, solving for true yields 1)
13 Likes
Rust does agree with C in that false is 0 and true is 1, it just requires the type cast to be explicit: true as u8 == 1. What Rust rightly avoided is the other direction of giving integer values an inherent interpretation as truth values, instead requiring spelling it out like x != 0.
2 Likes
Right. My post was intended as an argument to stop this unholy conflation (
) where it currently is and let it proceed no further. In my opinion, the .into() and as u8 are mistakes already.
1 Like
Iverson bracket notation (i.e., [true] = 1 and [false] = 0) is incredibly useful. In a language like R it is idiomatic to use bracket notation; you can write mean(x > 0) to estimate the probability that X > 0 (if x is a vector of samples of the random variable X). I believe that it should be explicit but without .into() how would you propose writing it?
2 Likes
Not sure what exactly you're asking (I don't know R and R syntax is not relevant to Rust), but if it is about getting from bool to u8 I'd prefer a specific method like bool::to_u8(self). The other direction is easily done using integer comparison operators.
You should learn some R! It is a beautiful language and it is very useful as a desk calculator. (Unfortunately Python seems to be eating the world.) Just because it's not Rust doesn't mean it couldn't be relevant to a discussion of Rust.
I was just trying to emphasize that having succinct notation to convert bool to an integer is extremely important. I don't think it should be implicit but if anything the current syntax is too verbose (I am not proposing an alternative though).
it is sometimes useful to write branchless code. For the most part the compiler is able to optimize simple branches, but it doesn't always work.
[true] and [false] are already arrays containing a single bool in Rust, so this doesn't seem applicable here. Also, at first sight I would not say that the operation being done is a conversion to an integer, as opposed to true as u8 and false as u8.
What is the bracket notation here? I don't even see square brackets.
Is it really that important though?
You don't have to write bracket notation with brackets. What I'm trying to say is that converting booleans to integers is an incredibly useful idiom. Some comments in this thread suggest that it is mathematically meaningless or that it was a mistake to even offer conversions with as.
3 Likes
This doesn't actually compile because both Add and Into are implemented for multiple types here and the type system is not smart enough to figure out the unique type that is in both sets.
4 Likes