Clippy nursery and const fns

help
1

Hello,

Clippy version is 1.86 and it is set to:
#![deny(clippy::all, clippy::nursery, clippy::pedantic, clippy::cargo)]

It suggests me following:

error: this could be a `const fn`
   --> hi\src\state.rs:99:5
    |
99  | /     pub fn toggle_focus(&mut self) {
100 | |         (self.last_focused, self.focused) = (self.focused, self.last_focused);
101 | |     }
    | |_____^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#missing_const_for_fn
help: make the function `const`
    |
99  |     pub const fn toggle_focus(&mut self) {
    |         +++++

I'm wondering if I'm misunderstanding something or is it Clippy being a little bit to aggressive and this is false-pos?
It suggests this for few other methods that modify self.

In rust, does it make any sense for a function/method, that takes any &mut to be const ?

P.S. I've tried replicating it on rust playground, although I can't seem to force clippy there to generate such warning.

2

const means the function can be called in const context, it doesn't mean the function is "read-only" to its arguments or something the like.

6 Likes
3

const doesn't imply whether it is mutable - mut does that.

4

This setting is far too strong. Clippy lints in general are known to have some false positives (they intentionally are a little more eager than rustc lints) and clippy::nursery in particular is the category for lints that are currently too prone to firing when they shouldn't. It doesn't make sense to deny them, nor to enable all of nursery.

6 Likes
5

The pedantic group of lints is not for things that you definitely should be doing. They're nitpicks, they're details that may not be worth caring about, they're things that depend on the context and situation that is beyond understanding of clippy.

This lint shows you which methods could be const. That's useful for when you want your library to be usable in const contexts as much as possible, and have Clippy flag functions which you forgot to mark const or didn't expect they'd work (especially that Rust is slowly adding support for more things in const contexts). If your types aren't used like that, then don't listen to that lint.

1 Like
6

I'm aware of that. Is it fair/safe, to treat rust const functions as pure functions?

7

Right now, that is the case, but there are no guarantees of the sort for the future. The only thing const fn means is that it can be called in a const context. Nothing more, nothing less.

1 Like
8

Depending on your definition of pure, it's already not the case. You've been able to panic in const since Rust 1.57 (which typically prints a backtrace at runtime), and non-deterministic float semantics landed in 1.82.

9

Yeah, didn't want to go into that discussion, as that ends up in vim vs emacs universe.