Bitflag types are awkward to use. Should it use the bitflags crate?

[ids1024]

If I bump the x11rb dependency in smithay to 0.11, there are errors like this:

error[E0369]: no implementation for `ConfigWindow & u16`
   --> src/xwayland/xwm/mod.rs:925:37
    |
925 |                     if r.value_mask & u16::from(ConfigWindow::X) != 0 {
    |                        ------------ ^ -------------------------- u16
    |                        |
    |                        ConfigWindow

Having both types be ConfigWindow seems like an improvement, but it seems like ConfigWindow doesn't implement BitAnd or have a contains() method, and the only way to fix this code is to convert both sides to u16? Unless there's something I'm missing here.

Would it be better to make use of the widely-used bitflags crate to define types like this? Then it would have all the methods I'm used to seeing in Rust bitflag types.

[psychon]

I think this is more or less already handled by #768 which adds a BitAnd impl for ConfigWindow. Later, #769 added .contains() which seems to be what you are looking for here.

Now I wonder whether it is worth doing a 0.11.2 with these PRs cherry-picked... Opinions?

[ids1024]

Ah yeah, .contains() covers this use case. The bitflags crate has a few other convenient methods and trait implementations, but I don't know how many would be useful for the APIs in x11rb.

I don't know this alone particularly warrants a release, but I don't know how much it benefits other consumers of the library.

[notgull]

In terms of rust-windowing/winit#2614, it would make checking certain bitflags significantly easier.

[psychon]

Also related: #904