Description

From #8071:

I ran the lint on 25 crates with lintcheck and got about 60 reports, the once I've looked at seem to be correct. upside_down_face

While I agree with the notion that the result of methods taking self argument and returning Self very likely should be used, I am less convinced that adding the lint without a period for consideration is appropriate. As noted above, it's high impact. In one project alone, I counted 71 affected methods. Given this, the new lint deserves extra consideration.

Mostly, this lint hits builder methods without side-effects where obtaining the output is the whole point.

#[must_use] was originally a tool for pointing out potentially dangerous behaviour, notably forgetting to check the result of a method returning Result<(), Error>. Using it to point out forgetting something harmless feels like abuse. Clippy is free to complain about generating unused values, but that's not what's happening here: it pushes the lint onto the compiler proper for users of the library using Clippy.

Regarding libstd, I see that std::ops::Add::add does have #[must_use] (since four years ago), and here there is justification: x + 1; looks quite similar to x += 1;. Similarly, fn f64::floor(self) -> Self has #[must_use] (users might assume that the method mutates its own state). In contrast, Option::filter, Option::map, etc. don't (users may abuse side-effects here, but it feels like bad style). Iterator does have #[must_use] on everything. OptionOptions::new has #[must_use] (even though it's a boring constructor). Rc::into_raw doesn't have #[must_use] but should (memory leak), though this wouldn't be picked up by this lint anyway. Duration::from_nanos does even though it's obviously a constructor. So the standard library is not entirely consistent but seems to err on the side of using #[must_use].

Back to this lint, I'm not sure what to think about it. It can't be called a style lint but does it actually prevent dangerous behaviour?

Version

No response

See also

• MCP for adding #[must_use] annotations throughout the standard library

Additional Labels

@rustbot label +C-question