Why Clippy giving a warning on changing a value sign?

code review
1

I noticed warnings like that

warning: this looks like you are trying to use `.. -= ..`, but you really are doing `.. = (- ..)`
   --> ./lib.rs:325:42
    |
325 |                         if neg {num_value =- num_value}
    |                                          ^^^^
    |
    = note: to remove this lint, use either `-=` or `= -`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#suspicious_assignment_formatting
    = note: `#[warn(clippy::suspicious_assignment_formatting)]` on by default

Is there any reason for that?

2

Presumably because intentionally writing a = -b as a =- b is strange and nonstandard. Rustfmt will fix that for you.

11 Likes
3

Thanks.

4

The "suspicious" lints like this are about detecting unusual code that's a small hamming distance from usual code. The - and = keys are right next to each other, so =- is a pretty easy typo to make.

Plus, why would you want to write a prefix operator with a space after but not write a binary operator with a space after? Use conventional formatting. It's conventional for a reason.

5 Likes
5

Clippy Lints :

suspicious_assignment_formatting

suspicious warn

What it does

Checks for usage of the non-existent =*, =! and =- operators.

Why is this bad?

This is either a typo of *=, != or -= or confusing.

Example

a =- 42; // confusing, should it be `a -= 42` or `a = -42`?
1 Like
6

I have the 'Apple' disease (not curable by the simple rule: an apple a day keeps a doctor away), I like everything to do different. So, I didn't use rustfmt and prefer my own source formatting style. One day, I did a significant code change and big portions of my code lost formatting. It requires a big effort to reapply it and I decided to try rustfmt before committing my changes in git. Imagine my woe when the code was completely not readable after the rustfmt work.
So I restored the old version from git and applied all changes I did before again. No rustfmt for me since that time.

I agree also considering that many people have a dyslexia.

Conclusion: If you decide to use rustfmt, then run the clippy first and the rustfmt after.
Recommendation: modify Rust language grammar requiring a blank after `= .

7

That would require an edition, and even then it requires significant reason for the breakage. Not wanting to use a built-in and recommended tool just because a lint correctly warns against it is unquestionably not going to meet the threshold for breakage.

Also note that Rust is not a whitespace-sensitive language. Two consecutive symbols, assuming they are permitted semantically, generally don't care if there's a space in the source code. The only cases where this isn't the case is ::, .., and similar, all because the characters are one token semantically. That's not the case here, so why should it be different than literally every other situation?

5 Likes
8

I am fine with completely blankless languages. A matter of fact, I wrote such language 2 years ago, so blanks can be used in variable names, like:

the a=3
the b=the a/3

However, I do not like the inconsistency of Rust. Why can't I put blanks between =>?, but I can write =- or = -. Anyway, this talk about nothing, we can't change Rust and just can more efficiently use it. So my point was, although the Rust tool chain gives very nice tools, we need be careful using them.

9

As I said:

=> is one "thing". =- is not.

1 Like
10

Because, as in most languages, you can leave out whitespace between tokens, but you cannot introduce whitespace into tokens.
=> is one token. = and - are two separate tokens.

2 Likes
11

Minor tip: If you want to guard against accidental rustfmt invokation, create a rustfmt.toml or .rustfmt.toml containing:

disable_all_formatting = true

The Rocket project does this to make sure contributors don't have rustfmt run amok on the project's formatting. (Plenty of Rust developers have "format on save" enabled in their editor).

2 Likes
12

I got the suggestion.