Is `.chunks` of `BitArray` considered internal API?

Currently I have a use case where I essentially need to pack AbstractVector{Bool} into the .chunks representation (i.e. each bit represent a bool value and “pad” to the smallest # of bytes that can accommodate the bits).

The easiest way is to just BitVector(my_vec).chunks, but I suppose this is technically internal. Maybe there’s a function to access the chunks of BitVector that is better than directly get that field?

I’d say that, yeah, it’s internal.

Tangentially related:

I feel like chunks are de-facto public since most fast algorithms using bitarray require using them

2 Likes

Yeah, but maybe again the tooling around BitArray should improve to provide fast operations without resorting to implementation details, right?

3 Likes

right, so maybe something public that either extracts chunks from BitArray or construct chunks directly would be separately useful

2 Likes

Would this be a suitable role for a reinterpret(UInt64, ::BitArray) method? I’m quite sure that does not work now, but that seems pretty close to the target semantic. The main snag is that it loses the length information (padding to the next largest multiple of 64, presumably), whereas normally reinterpret is very diligent about ensuring and preserving that.

Another possibility would be parent(::BitArray), but that might be a little too much of a pun since a BitArray isn’t (semantically) a wrapped array.

With those issues, these don’t really seem any better than a.chunks.

maybe a good fix is to just document the chunks property of BitArray as public api? That’s what stat does. That seems simpler than making an accessor and declaring all existing .chunks invocations as non-blessed, and with property overloading there’s still some flexibility.

1 Like