# \[ANN\] EmulatedBitIntegers.jl

**URL:** <https://discourse.julialang.org/t/ann-emulatedbitintegers-jl/137830>\
**Category:** Package Announcements\
**Created:** [June 28, 2026, 5:01am UTC](https://discourse.julialang.org/t/ann-emulatedbitintegers-jl/137830 "2026-06-28T05:01:02Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![matthias314](https://avatars.discourse-cdn.com/v4/letter/m/a88e4f/32.png) [@matthias314](https://discourse.julialang.org/u/matthias314)\
**Post date:** [September 9, 2026, 11:32pm UTC](https://discourse.julialang.org/t/ann-emulatedbitintegers-jl/137830/17 "2026-09-09T23:32:45Z")

</div>

> [@PatrickHaecker](#):
>
> `UInt8` use cases

Yes, that would be sufficient for most (but not all) use cases. However, I wonder how much difference it would make. Unless the bit mask has only one byte, alignment rules prevent memory savings for smaller length types (without packed structs, that is).

Introducing an additional parameter for the length type would make `PackedVector{U,M,T}` an abstract type, which is somewhat inconvenient. More importantly, I’m thinking of storing the length inside the bit mask and not as a separate field. That would solve the alignment issue.

> get rid of your type parameter `M`

I agree. The current first step is to make the existing API work with EmulatedBitIntegers.jl. If the parameter `M` is removed, then one has no choice but to use `EmulatedInteger` types. There are still some open [issues](https://github.com/JuliaData/EmulatedBitIntegers.jl/issues) with them. I’d like to wait until they are sorted out before I make that switch.

---

_[View the full topic](https://discourse.julialang.org/t/ann-emulatedbitintegers-jl/137830)._