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.
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.
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)
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
.
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.
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?
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
.
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.