Related: #188, #200, #207, #208, #211

@niklasf @KodrAus worked on #200

Bump!

I'll do the PR if needed

Hi @CasperN! 👋

We can't consider any changes to the bits() method, because the library is already stable.

The way we modeled this originally was that the flags represents a closed enum, where the set specified in the definition is the complete set of possible flags the enum could combine. Since not all valid bit patterns of the underlying integer type are valid bit patterns of the flags it's not safe for us to simply accept any integer and treat it as valid flags. So we made the unchecked method unsafe.

If we wanted to clean up the semantics we could consider allowing an #[open] attribute or something on the bitflags! definition itself, so you'd declare an open bitflags that could happily accept any integer, assuming it's not the source-of-truth for what flags exist:

bitflags! {
    #[open]
    struct Flags: u32 {
        const A = 0b00000001;
        const B = 0b00000010;
    }
}

Then let these #[open] bitflags have #[repr(transparent)] and so can be soundly transmuted to and from the given integer type, making from_bits_unchecked safe.

What do you think?

We could also use #[repr(transparent)] for this. I don’t think that’s too much of a semantic hijacking, so long as it also does apply the attribute.