Criteria for adding `[must_use]`?

[kornel]

Does libcore/libstd have a criteria for which functions should have #[must_use]?

Is there any downside to having #[must_use], assuming it's placed correctly (i.e. it never makes sense to call a function and not use its return value)?

[Ixrec]

I'm not aware of anything beyond the generic rule that rustc lints should have extremely few or no false positives.

[varkor]

There's an existing discussion on this topic here: https://github.com/rust-lang/rust/issues/48926.

[mbrubeck]

This reminded me that I've been wanting a corresponding #[must_not_use] attribute for a long time. I wasn't able to find an existing issue or RFC (but I might have missed something), so I just filed one here:

Warn on useless bindings like `let v2 = v1.sort();`

[kornel]

From the discussion it sounds like it's OK to add must_use to side-effect-free functions, and whenever it doesn't make sense to use a function without its returned value.

In particular, I've found @cuviper made the exact same PR I was going to do

Lint must_use on mem::replace

[Dante-Broggi]

Just as an interesting bit of inter-language context:
Swift used to have an equivalent to [must_use] @warn_unused_result, but replaced it with @discardableResult for all non Void/() returning functions.

[scottmcm]

@kornel

Does libcore/libstd have a criteria for which functions should have #[must_use] ?

Is there any downside to having #[must_use] , assuming it's placed correctly (i.e. it never makes sense to call a function and not use its return value)?

Mostly it's fine, other than that it's a non-goal to put it on everything where it could be.

For example, it's useless to call Vec::len() and not look at the result, but it also really doesn't actually cost anything. The goal is for "obvious" things like that to eventually have their own lint.

But if there's some particular reason that a specific ABI would be more valuable than most to have it, then it's fine to get one. See the issue varkor linted for more detail.