Introduce bit-vec-extra and bit_vec::extra

[pczarn]

This is a fork of Alex Payne's bitvec.

See also:

• ferrilab/bitvec
• Any known fork of bitvec/radium? ferrilab/bitvec#297

[pczarn]

@Jujumba
@theroguevigilante
I could use your input on this because it will be a huge change and a huge addition

[pczarn]

I spoke to Alex Payne and got his permission to maintain the code.

[theroguevigilante]

give me some time I would take a look into it

[pczarn]

My idea, further, is to create a new crate bit-defs

with code like this

bitdefs! {
    enum FileType { File, Directory }

    enum Permission { Forbidden, Permitted }
    
    struct Rwx {
        read: Permission @ 0,
        write: Permission @ 1,
        execute: Permission @ 2,
    }
    
    #[repr(u8)]
    struct FilePermissions {
        file_ty: FileType @ 0,
        owner: Rwx @ 1,
        group: Rwx @ 1 + 3,
        all: Rwx @ 1 + 3 + 3,
    }
}

[theroguevigilante]

@pczarn I am not against the idea of bit-defs, but it would better to hold it until we have better docs and some active maintainers.

[theroguevigilante]

@pczarn Looking into it, I dont think dropping the old bitvec whole as bit-vec-extra is a good idea, it would be better if we cherry-pick functionality that we currently lack.

[pczarn]

@theroguevigilante not sure how to proceed, because ideally we would maintain the full code of bitvec. The downside is it is a big undertaking, but someone has to step up to do it.

[theroguevigilante]

@pczarn isn't it better to have a migration guide so that anyone who is looking to stop using the unmaintained one can switch to ours also in the meantime we can look for stuff that our implementation lacks, also something that can be considered is having some sort of a compat crate that can use our crate in a similar manner to Payne's API (tho, I havent looked into it to conclude if it can be done meaningfully), I particularly dont find the idea of using an old crate as an extra.

[pczarn]

@theroguevigilante What if I made Payne's code work just fine on top of our data? Basically giving ours many additional methods.

[pczarn]

@theroguevigilante I think I figured out a way to do this with traits. How would you use the trait system to generalize the methods we have for types such as u32, Vec<u32> and Payne's BitVec? I think many types can benefit from our methods, and it fits into making it generalized for another crate.

[theroguevigilante]

@pczarn I have a way to tackle this using feature gating, basically we can have a feature that would allow users to opt in and use payne's work and implement the trait for u32, u16, u8 etc, for example BitStore is already implemented for those types. If u want I can open a pr for you to review.

[pczarn]

Sure, go ahead and i will review.