Higher parity with std's `Vec`

[pczarn]

ferrilab's bitvec is probably a drop in replacement for Vec

Roadmap

• from_raw_parts
• to_raw_parts
• drain
• insert (Insert & insert many #92 )
• push_within_capacity
• remove
• ...

[pczarn]

we are missing some important stuff such as 'from_raw_parts'

[pczarn]

We cannot implement to/from_raw_parts until #9 is done

[Jujumba]

Consider also adding push_within_capacity

[Jujumba]

How would interface for from_raw_parts/to_raw_parts look like? I think the following is reasonable:

impl<B: BitBlock> BitVec<B> {
    // `num_of_bits` = nbits
    // `length` = number of Bs behing `ptr`
    pub unsafe fn from_raw_parts(ptr: *mut B, num_of_bits: usize, length: usize, capacity: usize) -> Self;

    pub fn to_raw_parts(self) -> (*mut B, usize, usize, usize);
}

Though the wording may be a bit confusing (someone may mix up num_of_bits and length).

Also, do we really want to have to_raw_parts instead of into_raw_parts for higher parity?

@pczarn

[Jujumba]

How would interface for from_raw_parts/to_raw_parts look like? I think the following is reasonable:

impl<B: BitBlock> BitVec {
// num_of_bits = nbits
// length = number of Bs behing ptr
fn from_raw_parts(ptr: *mut B, num_of_bits: usize, length: usize, capacity: usize) -> Self;

fn to_raw_parts(self) -> (*mut B, usize, usize, usize);

}

Though the wording may be a bit confusing (someone may mix up num_of_bits and length).

Also, do we really want to have to_raw_parts instead of into_raw_parts for higher parity?

@pczarn

I think using num_blocks and num_bits (instead of length and num_of_bits) is less confusing and more concise

[Jujumba]

How would interface for from_raw_parts/to_raw_parts look like? I think the following is reasonable:

impl<B: BitBlock> BitVec {
// num_of_bits = nbits
// length = number of Bs behing ptr
pub unsafe fn from_raw_parts(ptr: *mut B, num_of_bits: usize, length: usize, capacity: usize) -> Self;

pub fn to_raw_parts(self) -> (*mut B, usize, usize, usize);

}

Though the wording may be a bit confusing (someone may mix up num_of_bits and length).

Also, do we really want to have to_raw_parts instead of into_raw_parts for higher parity?

@pczarn

@pczarn , any thoughts on this?

[pczarn]

Users can do (bv.len(), bv.storage_mut().into_raw_parts())

Should have way to go in the opposite direction

We need to add conversion from storage + num_bits to bit-vec

[pczarn]

Ah, I see the problem with our api for this

[pczarn]

Why on earth do I not write down my thoughts?