Repository navigation
Odd sequence of BTreeSet impls and iter doesn't require T: Ord #47138
Description
From the docs for BTreeSet:
We see four impls, but there really should be just one. It's also interesting that iter doesn't require T: Ord. These impls are much different from the ones in BTreeMap, HashSet, and HashMap. I see no reason for why they should be written this way.
Should we put all methods in just a single impl<T> BTreeSet<T> where T: Ord block instead?
Technically, that'd be a breaking change since iter currently doesn't need T: Ord, but you can't construct a BTreeSet without the bound anyway. You can reach for unsafe to create a BTreeSet<T> even if T doesn't impl Ord, but it's very unlikely that such code exists in the wild. In any case, I'd consider the missing bound on iter simply a bug.
Activity
vitalyd commentedon Jan 2, 2018
It’s a breaking change because existing generic code that takes a
BTreeSet<T>and callsiter()may not be specifying theT: Ordbound. With the proposed change, they would have to (even if they don’t otherwise care about the ordering).bluss commentedon Jan 2, 2018
Yes please group the methods into fewer impls. Whatever presents it better in docs, if the API is equivalent either way.
vitalyd commentedon Jan 2, 2018
Yeah that sounds reasonable. It’d be nice if rustdoc could do this grouping on the UI side so the code could be organized any which way.
scottmcm commentedon Jan 3, 2018
This is actually convenient for reducing typing if you need to loop through the set but don't care about changing it -- display it, sum it, whatever -- since you can just have
<T>on your function.Rollup merge of rust-lang#47162 - stjepang:cleanup-btreeset, r=alexcr…