Closed godel9 closed 8 years ago
The reason is essentially consistency with the other set types (e.g. BTreeSet
).
Maybe some day there will be a trait for all Set. Until then, I don't think the consistency issue is very relevant.
Arguably they should be taking an &Q
where Q: Borrow<usize>
to match the other collections.
This was somewhat annoying in some cases where I was casting, so the calls looked like:
bitset.remove(&(value as usize));
I could buy @Gankro's argument, though.
In VecMap we recently merged this change on the reasoning that any future collection trait can be used to paper over this difference. Happy to accept a PR.
the remove and contains methods for bitset take an argument of type &usize, but there seems to be no reason for this instead of just taking a usize directly.