Before we actually release a build with #220 I think it’s a good time to consider any breaking changes that could work their way into a 2.0 release. Without much public surface area I think the risk of multiple bitflags versions in a dependency graph is low.

Some I had in mind:

• Reconsider making from_bits_unchecked unsafe. The idea was to make it unsafe to construct flags using bits that don’t correspond to flags specified. That way an implementor could consider using things like unreachable_unchecked in code that matches on bits. In hindsight this just seems like something people work around rather than make use of. Since we generate types in the scope of the bitflags! invocation there’s already nothing stopping someone from manually stuffing extra bits in a flags type. So we can’t rely on from_bits_unchecked in bitflags code either.
• Consider not deriving any traits by default. Ship an optional proc macro #[bitflags_derive] that can be used to add them. That way callers can decide on their own equality and debug implementations if they want.
• Consider changing the serialization implementation to use a text format for human-readable formats and raw bits for others.
• Anything else?