Odd sequence of BTreeSet impls and iter doesn't require T: Ord

[ghost]

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.

[vitalyd]

It’s a breaking change because existing generic code that takes a BTreeSet<T> and calls iter() may not be specifying the T: Ord bound. With the proposed change, they would have to (even if they don’t otherwise care about the ordering).

[ghost]

You're right -- that didn't occur to me.

In that case, perhaps we should just group all the methods that do require T: Ord in a single impl block to make the generated docs cleaner.

[bluss]

Yes please group the methods into fewer impls. Whatever presents it better in docs, if the API is equivalent either way.

[vitalyd]

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]

It's also interesting that iter doesn't require T: Ord.

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.