Suggest casting bool to int instead of using if statement.

[cwhakes]

What it does

Instead of using an if statement to convert a bool to an int, this lint suggests using a coercion or a from() function.

Lint Name

bool_to_int_with_if

Category

style

Advantage

• Makes code more concise
• Makes this conversion more discoverable

Drawbacks

• None

Example

if condition {
    1_i64
} else {
    0
}

Could be written as:

i64::from(condition)

or

condition as i64

[xFrednet]

Thank you for the suggestion. I think the lint description should also mention that Rust guarantees that true will be 1 and false will be 0 when casted to an integer. source.

This lint should be fairly simple to implement 🙃
@rustbot label +good-first-issue

[bsimon12]

@rustbot claim

[xFrednet]

Hey, @bsimon12, I've unassigned you from this issue, since it has been a long time since you've claimed it. If you want to continue work on this or select another good-first-issue you can always claim it again 🙃

[jst-r]

@rustbot claim

[jst-r]

I've mostly finished working on it.

It's not quite clear to me whether to include both as and from as suggestions?

Also, it seem like dealing with parenthesis around condition in as coercion is not trivial. Is it okay to always include them?
Example

// parenthesis needed because coercion has higher priority than boolean operations
let x = if a || b { 1 } { 0 };
// fixed
let x = (a || b) as usize;
// fixed without parenthesis
let x = a || b as usize; // error[[E0308]]: mismatched types

// parenthesis not needed
let x = if a { 1 } { 0 };
// fixed with parenthesis
let x = (a) as usize; // not ideal

[xFrednet]

Hey @jst-r, thanks for picking this up!

It's not quite clear to me whether to include both as and from as suggestions?

It depends on if you want to make the suggestion automatically applicable. Then it would be better to only emit one suggestion. I would suggest only using from() as that would also solve the parenthesis problem. <ty>::from(<expr>) should always work, while <expr> as <ty> might require parenthesis, as you've mentioned.

If you want to take the extra step, and create an as suggestion, you can look at the parent/child expressions of nodes to figure out if you need the parenthesis. But that is probably more complicated than it needs to be 🙃

[jst-r]

Thanks for suggestion, @xFrednet !

I've already implemented automatically applicable version (I hate when I can't just ctrl+. to fix something). To do so I've commented as suggestion out.

I feel like trying to decide if parenthesis are needed would have a lot of edge cases. And as a consequence possible bugs.

After running dogfood test, I think .into() conversion would be more concise and (imho) more readable.
For example returning from function using has_own.into() feels less noisy than usize::from(has_own).

But it comes with the same challenge as as. And type inference seems flaky at times.
Example: let x: i32 = 1i32 + (a || b).into(); doesn't compile on stable.
It probably can be fixed by some checks on parent nodes.

I'm not sure I'll be able to handle all the cases. But .into() seems like a good thing to suggest.
Always suggesting from and adding a note about into may be a reasonable middle ground.

What do you think about it?

[xFrednet]

Finding the reasonable middle ground is the hard part about writing lints ^^ (I tend to get carried a way when I work on them 😅 )

I feel like trying to decide if parenthesis are needed would have a lot of edge cases

I don't think that it would have many edge cases, since as has a high precedence https://doc.rust-lang.org/reference/expressions.html#expression-precedence

As a simple fix, you could check if the boolean expression is a Path/Method/Function/Array expression and otherwise suggest parenthesis. That would be simple enough, and I prefer the as <ty> suggestion a tiny bit.

Always suggesting from and adding a note about into may be a reasonable middle ground.

This is also a very good option. What do you feel like? As a lint author, you also have some freedom when it comes to this 🙃.

[jst-r]

I get why why you prefer as <ty>. After giving it a little more thought, as feels both as explicit as from and isn't too noisy.

As a simple fix, you could check if the boolean expression is a Path/Method/Function/Array expression and otherwise suggest parenthesis.

I haven't thought about it. It's definitely not too hard.

I'll implement version with as. And, hopefully, will open a PR tomorrow.