DynamicBitSetUnmanaged / DynamicBitSet missing methods?

Help
1

It seems like DynamicBitSetUnmanaged and DynamicBitSet are missing methods that the other BitSet objects have. One I specifically want to use is this complement method, but it isn’t implemented on DynamicBitSetUnmanaged. Is this an oversight? I can write my own implementations, but it seems to me that these BitSet objects should have mostly the same methods.

Thanks!

2

To answer my own question, apparently those methods would require an allocator so they weren’t implemented.

I will just write my own!

2 Likes
3

DynamicBitSetUnmanaged is missing some other methods too, like these:

1 Like
4

Complement in particular wouldn’t require an allocator, so it would make sense to send a PR (and then copy the implementation from the PR, as it would take six months for it to get merged :slight_smile: )

I feel like Zig’s bitset API in general could use a fresh coat of paint. The static bitset in particular is biased to the initFull() direction, which inflates binary size: stdx: vendor bitset by matklad · Pull Request #2833 · tigerbeetle/tigerbeetle · GitHub

1 Like
5

It would if you want to make it pure, which is a point that was stressed in the PR.
You could make it mutate the current object, but then the API would be different from the static version, which would be kind of unexpected.

1 Like
6

Ah, compliment returns a copy? Yeah, that wouldn’t make sense for allocating collections, they should use in-place API, and an explicit .clone method.

1 Like
7

Just for context, I implemented my own BitMap object and I’m trying to transition to use the BitSet from stdlib (my fault for not reading stdlib closely enough). The one I wrote is basically equivalent to DynamicBitSetUnmanaged, but I could write code like this:

var new = try bm.complement(alloc);

Now I have to do it in two lines with the caller mutating the new BitSet:

var new = try bm.clone(alloc);
new.toggleAll();

It’s not a big deal, it just seemed surprising that the functionality wasn’t there (and I like that in the first example I don’t have to mutate the new object to get a complement of the existing one).

Out of curiosity, is it a problem for complement to take an allocator? ISTM only DynamicBitSetUnmanaged would actually need the parameter since the DynamicBitSet form already has an allocator. Even if DynamicBitSetUnmanaged took an allocator as a parameter, that also seems fine since we already have API differences between the implementations. I could send a PR about it, but thought I’d post here first since I don’t feel “stylistically” confident in my Zig abilities :sweat_smile:

Thanks!