Please allow to use the "internal" derives in the "custom-derive" case about bitflags HOT 6 OPEN

The bitflags! { struct Qux: u32 { .. } } case currently just uses a newtype to make plain #[derive()]s work

That's what bitflags 1 was doing. bitflags 2 is different in that matter, which is the reason for this issue in the first place. Specifically, it uses a newtype of an internal type that #[derive()]s can't be applied to.

from bitflags.

Hi @glandium 👋

It looks like you're using the impl-style bitflags! because you also need support for other custom derives? It seems like there's more we can do to make that pattern nicer. Perhaps a proc-macro library that leveraged the Flags trait to offer its own custom-derives for Debug etc:

#[derive(bitflags::Debug, Foo, Bar)]
pub struct Qux(u32);
bitflags! {
  impl Qux: u32 {
    ...
  }
}

from bitflags.

It wouldn't need to be a proc macro, it should be possible to make this work:

#[derive(....)]
pub struct Qux(u32);

bitflags! {
    #[derive(Debug)}
    impl Qux: u32 {
        ...
    }
}

// produces the same Debug impl that this would produce:
// bitflags! {
//     #[derive(Debug)]
//     struct Qux: u32 {...}
// }

from bitflags.

Both would work, although the proc-macro would feel better because it groups the derive in a single place, but I can understand that it's more stuff to compile.

from bitflags.

My preference would be for a proc-macro, starting in an external library with the option to include in bitflags through a feature, but would never want to pull any proc-macros in to bitflags by-default. The reason I'd like to avoid macro_rules! for this is the macro logic in bitflags! is already quite complicated, and I'd like to avoid introducing any magic attributes wherever possible. The bitflags! { struct Qux: u32 { .. } } case currently just uses a newtype to make plain #[derive()]s work, since many custom-derives treat newtypes differently.

from bitflags.

bitflags 1.x used a struct like struct Flags { bits: u32 }, so you could #[derive] many things, but they would be based on that un-semantic u32 so probably not what you actually want to implement. bitflags 2.x uses a newtype like struct Flags(FlagsInner) where FlagsInner manually implements traits semantically so you can add #[derive]s on Flags and get something closer to what you want to implement, but has the (significant) drawback that only traits implemented by FlagsInner can be #[derive]'d on Flags.

from bitflags.