std::move will cast even mutable references, which makes hard-to-find bugs and is thus generally not wanted if the reference was passed to a function. So I don't think replacing forward with move is correct, unless you can provide a reason for the change.

std::move will cast even mutable references, which makes hard-to-find bugs and is thus generally not wanted if the reference was passed to a function. So I don't think replacing forward with move is correct, unless you can provide a reason for the change.

my mistake, I've dropped the commit

Yeah, we should probably check this with https://clang.llvm.org/extra/clang-tidy/checks/bugprone/move-forwarding-reference.html

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #25722 (refactor: Use util::Result class for wallet loading by ryanofsky)
• #24313 (Improve display address handling for external signer by Sjors)
• #22838 (descriptors: Be able to specify change and receiving in a single descriptor string by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

I assume this is being done with some automated tooling? If so, could you expand the PR description to describe what you are doing to produce the change?

Similar to #25707, if you want to make a change like this, we'd likely also want this enforced/linted in some way. Are there any checks you can use in https://releases.llvm.org/14.0.0/tools/clang/tools/extra/docs/clang-tidy/checks/list.html?

Can tooling ensure these member functions marked as const are all thread-safe?

I assume this is being done with some automated tooling? If so, could you expand the PR description to describe what you are doing to produce the change?

Done.

Also rebased.

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

why the close? Seems a risk free CI check to avoid spending time on this during review?

@MarcoFalke I was asked during coredev to close this.

This kind of code review-heavy codebase-wide refactor is not appropriate in general, especially for a new contributor. Constness can be accidental, and code/logical constness are not the same thing.