Add alternative way to handle bitvec-extra

[theroguevigilante]

@pczarn I propose this way too handle bitvec by payne, I have attached and example too that shows how exactly, it would work.

[pczarn]

I wanted something like this, but with traits with provided methods and required methods as well as perhaps extension traits, moving our code to something like extension trait provided methods. Thanks, i will think about it.

[pczarn]

What i would do much differently is that with an immutable reference to storage you cannot push, pop, insert, remove, extend etc.

[theroguevigilante]

@pczarn extension traits sounds nice, if you can add a snippet, I can more easily understand wym.

[pczarn]

@theroguevigilante

There are two major problems with this kind of bit-vec-extra.

• Having two different apis adds conceptual overhead. It does not intuitively make sense.
• Even if we added another api, the problem is stability. bitvec is on a stable version and if we do not offer similar high stability then it does not make sense to use our code. Our users should be very interested in stability.

[pczarn]

@theroguevigilante My suggestion is to merely add a BitSlice feature through bit-vec = { version = "0.12", features = ["slice"] } and some other features, through bringing in some of the code from Payne's while keeping it all unstable for now.

[pczarn]

pub trait BitSliceable<B: BitBlock> {
    fn slice(&self, r: Range<usize>) -> BitSlice<B>;
}

[theroguevigilante]

Is BitSlice the only desirable feature @pczarn ? I think first things first we should know which features from the previous codebase are needed firsthand, regardless of the approach we are going to take.

[pczarn]

Is BitSlice the only desirable feature @pczarn ? I think first things first we should know which features from the previous codebase are needed firsthand, regardless of the approach we are going to take.

The only frequently requested features are BitSlice and feature parity with std's Vec and [T]. Ferrilabs have perfect support for both. Whereas atomics with their concurrency are a niche use case of ferrilabs and we got only one request for them.

[theroguevigilante]

@pczarn In that case I think, it would be better to start with BitSlice and work our way from there. We can open a new pr for that and start working on it.

[theroguevigilante]

PS: Also we can discuss how exactly we are going to implement it.