Derive PartialOrd/Ord/Hash for bitflags structs. Implement Default for io::FilePermission

[nham]

I wanted to add an implementation of Default inside the bitflags macro, but Default isn't in the prelude, which means anyone who wants to use bitflags! needs to import it. This seems not nice, so I've just implemented for FilePermission instead.

[lilyball]

Hash I get, but what meaning does ordering have for bitflags?

[nham]

A collection of bitflags is just a string of bits, which can be lexicographically ordered. I'm not sure what meaning this has, but it's not very different from implementations of PartialOrd for other types (e.g. the PartialOrd for TreeSet is "list the elements in increasing order and then compare the lists lexicographically". I don't see the meaning of this)

[alexcrichton]

This should be marked as a [breaking-change] because anyone implementing these traits manually for a bitflags type will have to remove the manual implementations.

[lilyball]

@nham TreeSet is already semantically an ordered collection. While I agree that bitflags can be lexicographically ordered, I'm not convinced that there is in fact any meaning to the order of the bits and that, therefore, there's no actual meaning to ordering of bitflags.

The only argument I can come up with for deriving ordering for bitflags is so it can be used as a key in an ordered container. And maybe that's sufficient justification.

[nham]

@alexcrichton I think I've done this now. I just needed to add [breaking-change] to the commit message, right?

@kballard I guess maybe I'm not sure what you mean by "meaning". Do you mean whether or not there's a use for this ordering (outside of enabling the type to be used in an ordered container)? I guess that's where my hangup with TreeSet is, because I cannot think of a single use for it. There's also a degree of arbitrariness to it: why not list the TreeSet elements in descending order instead of ascending order before you compare the lists? Is there a strong argument besides "the iter() method currently yields elements in ascending order"? I think the bitflags ordering being defined here is similarly arbitrary and based largely on implementation details.

[alexcrichton]

You can find more information on the breaking changes policy here, the commit message should be expanded a bit according to the details of that email.

[lilyball]

@nham If it were up to me, I wouldn't have defined PartialOrd on TreeSet. But as long as it is defined, it seems to be to be relatively unambiguously correct to define it as comparing the values in order. Especially because, as you pointed out, it has an iterator that yields elements in order. In general, it seems reasonable to define an ordering for any iterable collection that yields orderable elements.

[nham]

@alexcrichton Thanks. I think I'm adhering to the breaking changes policy now, but please let me know if I'm missing anything.