Auto generate values when no values are specified

[qwerty01]

In some cases, the actual values of the bitfields may not matter to the user, so it would be nice to have another expansion such that:

bitflags! {
    struct Flags: u32 {
        const A;
        const B;
        const C;
        // etc
    }
}

gets automatically expanded to

bitflags! {
    struct Flags: u32 {
        const A = 0b001;
        const B = 0b010;
        const C = 0b100;
        // etc
    }
}

[KodrAus]

Thanks for the suggestion @qwerty01!

This seems reasonable to me. We've got concerns around forwards compatibility where flags inserted in the middle of the enum will change the meaning of any flags that appear after it, but that's already true of #[repr(n)] enums with default values for variants.

[shjohnson-pi]

Would it be trivial to also allow resetting the counter?

bitflags! {
    struct Flags: u32 {
        const A;
        // B not used currently
        const C = 0b0100; // reset counter
        const D;
    }
}

gets automatically expanded to

bitflags! {
    struct Flags: u32 {
        const A = 0b0001;
        //        0b0010 skipped
        const C = 0b0100;
        const D = 0b1000;
    }
}

[KodrAus]

@shjohnson-pi I think so long as our semantics for what gets inferred is just a left-shift of the previous flag that should work. If in your example you defined C as 0b0101 then we'd still have some idea of what to do next.

[tech6hutch]

@KodrAus since 2.0 is out (for the last several months), I guess that means this was rejected for 2.0?

[KodrAus]

@tech6hutch I think this is something we can add without breakage so it could be introduced at any time.

[tgross35]

Is this possible to do with the rules macro, or is a derive macro needed? There are probably some tricks to keep a counter within a rules macro, but that sounds like it could be more trouble then it is worth.

[Embers-of-the-Fire]

@tgross35 This is not that difficult to implement counter in rule macros, but it can lead to unintuitive and hard to read unfolding code. In fact, more importantly, integrating this functionality into the bitflag macro, which is already a rule macro, could make the macro itself difficult to understand and maintain.

[tgross35]

Maybe that will become more straightforward sometime soon :) rust-lang/rust#122808

(yes yes, MSRV)

[KodrAus]

I think we could probably also do this using constants, since we already build a constant array of flag values. Constants may be the best approach here since we'll naturally handle #[cfg]s through them. We could define the semantics as unspecified values are assigned the value at the previous index left-shifted by one (or 1 if it's the first flag).