impl TryFrom<T::Type> for BitFlags<T>

[arcnmx]

Misc notes:

• Submitting this for initial feedback on the approach, still needs documentation and tests
• This raises the minimum rustc version to 1.34.0 (from 1.31.0 currently due to syn 1.0 I think?). If that's too recent we could gate this behind a feature flag instead.
• This adds a std flag because although TryFrom doesn't have a type Error: std::error::Error bound, it's often useful to have that impl. I'm wary of making it default though, because it still seems ideal to keep the core crate no_std by default?
  • (I'm personally wary of any default Cargo flags in general because it feels way too easy for a dependency to not realise when it should be using default-features = false)
• Hard-codes the list of numeric types because generic/blanket impls don't mesh well with TryFrom. I was hoping the proc macro impl'ing it for BitFlags<Self> might work but that's not good enough for the orphan rules it seems.
• BitFlagNum modified to include fmt::Debug constraint because we kind of want #[derive(Debug)] struct S<T>(BitFlags<T>) to work?
  • This is making me think about generic BitFlags<T> in context though... We hide BitFlagsRaw as an internal trait despite the fact that it's required for BitFlags<T> and thus pretty crucial for doing any generic operations over bitflags... I'm questioning whether we shouldn't re-export this publicly at the root of the crate? (if we don't want manual impls and want to still require use of the proc macro, we can still make the trait fns themselves doc(hidden))
  • There are a few points around the ergonomics of BitFlags<T> vs T that I'd like to address I think... Hm.

[meithecatte]

I don't think these should be also exposed as a method. A trait would be enough. In fact, I'm considering #[deprecating] from_bits once this lands.

[arcnmx]

Huh, I disagree with that philosophy in that I find generic conversion traits often unwieldy to use explicitly when you need them, because type inference often needs help via extra type hints/ascriptions when using something(BitFlags::from) - whereas BitFlags::from_bits assists inference and improves readability. I guess I'm not personally a fan of using conversion traits outside of generic arguments when there's a better explicit option (usually that's ::new I guess).

[meithecatte]

Since this is a public API, it'd be nice to have a sentence or two of documentation here. You could even write a doctest which tries to convert a number with some invalid flags and then asserts about the results of truncate and invalid_bits. This would kill two birds with one stone, since there aren't really any tests for this functionality right now.

[meithecatte]

It's not necessary to use 3 rules here. I've pushed a commit onto your branch that shows how this can be done, though ideally it would be squashed into this one.

[arcnmx]

Makes sense, will make sure to get it all get squashed/cleaned up once it's ready.