Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add #[must_use] to {HashMap,HashSet,BTreeMap,BTreeSet}::insert #93107

Closed
wants to merge 1 commit into from
Closed

Conversation

safinaskar
Copy link
Contributor

I propose adding #[must_use] to methods insert of HashMap, HashSet, BTreeMap, BTreeSet.

Because in my code I always want to check whether such key existed before. And it is easy to forget such check. My current workaround is so: I forbid direct calls to HashMap::insert and similar functions using clippy::disallowed_methods and wrap this functions using wrappers with #[must_use]. I propose simply to add #[must_use] to std.

Yes, I am aware about try_insert ( #82766 ). But this functions is misnamed: prefix try_ is usually used for functions, which can report allocation error, such as HashMap::try_reserve. Also, this doesn't fix the problem for HashSet

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 20, 2022
@veber-alex
Copy link
Contributor

I think this is going to be very annoying for a lot of people, I personally never needed the return value of insert.
A lot of code will need to start doing:

let _ = map.insert(1, 2);

or disable must_use all together.

@ChrisJefferson
Copy link
Contributor

Have you considered seeing if something like this could added as an (optional) clippy?

I agree with @veber-alex -- I just looked and I have many inserts, and have never checked the return value of any of them. I personally feel [must_use] should be reserved for cases where without using the return value the function simply doesn't do anything useful, which doesn't apply in this case.

@joshtriplett
Copy link
Member

I agree as well: we use #[must_use] in cases that very nearly can't have false positives, by the nature of the method. There's no point in calling len if you don't save the length; there's absolutely a valid use case for calling insert and not caring if the item was already present.

An optional (allow-by-default) clippy lint might be a good idea, for projects that want to enforce this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants