Vec::dedup_by provides mutable references to the FnMut that's passed in.
Why does it do this? Mutating a value while you're trying to dedup it doesn't make much sense, that sounds like a job for an iterator to do first.
At a glance, this could be used to merge elements (union, concatenation, etc.) rather than strictly deduplicating: mutate the first to include the second, then declare the second a duplicate. Assuming that works, it would be nice if it were documented as an example use case.
But in general, it's good to pass on mutable references to the callback so as to not unnecessarily restrict the uses of the function.
A long time ago this was asked in an issue, too: Why does dedup_by/by_key needs &mut T to check equality ?
It's strictly more flexible to provide a mutable reference than a shared reference.
If you don't do it the unnecessary limitation might eventually annoy sufficiently many users that you end up needing a new second version of the API that does offer mutable references.
5 Likes
Since the operation requires mutation anyway, there is no drawback, and possibly benefit even if just in corner cases, to passing a mut ref to the callback.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.