Auto generate values when no values are specified

qwerty01 commented

2021-02-16 10:29:01 -06:00

(Migrated from github.com)

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
    }
}

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: ```rust bitflags! { struct Flags: u32 { const A; const B; const C; // etc } } ``` gets automatically expanded to ```rust bitflags! { struct Flags: u32 { const A = 0b001; const B = 0b010; const C = 0b100; // etc } } ```

👍 22

KodrAus commented

2021-07-18 19:53:22 -05:00

(Migrated from github.com)

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.

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 commented

2022-02-19 09:33:57 -06:00

(Migrated from github.com)

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;
    }
}

Would it be trivial to also allow resetting the counter? ```rust bitflags! { struct Flags: u32 { const A; // B not used currently const C = 0b0100; // reset counter const D; } } ``` gets automatically expanded to ```rust bitflags! { struct Flags: u32 { const A = 0b0001; // 0b0010 skipped const C = 0b0100; const D = 0b1000; } } ```

KodrAus commented

2022-05-03 19:23:40 -05:00

(Migrated from github.com)

@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.

@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 commented

2023-08-21 08:46:15 -05:00

(Migrated from github.com)

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

KodrAus commented

2023-08-24 16:48:19 -05:00

(Migrated from github.com)

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

👍 2

tgross35 commented

2024-02-05 19:31:23 -06:00

(Migrated from github.com)

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 commented

2024-03-22 22:48:42 -05:00

(Migrated from github.com)

@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 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 commented

2024-03-22 23:38:50 -05:00

(Migrated from github.com)

Maybe that will become more straightforward sometime soon :) https://github.com/rust-lang/rust/pull/122808

(yes yes, MSRV)

Maybe that will become more straightforward sometime soon :) https://github.com/rust-lang/rust/pull/122808 (yes yes, MSRV)

KodrAus commented

2024-03-23 18:55:51 -05:00

(Migrated from github.com)

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).

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).

Rows
Columns

Auto generate values when no values are specified #236