We should be able to create a ByteSet from a..b or a..=b where a and b are u8, and have it be usable in const.

The API should look like:

• const fn from_range(range: std::ops::Range<u8>) -> ByteSet
• const fn from_range_inclusive(range: std::ops::RangeInclusive<u8>) -> ByteSet

I expect this would be implemented via bit tricks over the integer chunk representation.

It would be nice if, at least for every tagged release, the entire benchmark suite could be automatically run. Then results could live at e.g. https://nvzqz.github.io/byte-set-rs/benchmarks/v0.1.0/ and https://nvzqz.github.io/byte-set-rs/benchmarks/latest/.

There are comparison benchmarks between ByteSet and the following types:

• [bool; 256]
• BinaryHeap<u8>
• BTreeSet<u8>
• HashSet<u8>
• InclusiveRange<u8>
• Vec<u8>

What other types should be compared against?

Motivation

There are currently no guarantees about ByteSet's internal memory representation. Each byte should always map to a specific bit across compatible versions when targeting the same architecture.

This would enable the library to be ported to other languages (e.g. C, C++, D, Swift) and have the same instance be sent directly across each language.

Target-specific behavior

Properties that are allowed to change the representation are:

• Endianness
• Pointer width

This allows for various optimizations while still being consistent.

ByteSet is composed of [u64; 4] or [u32; 8] depending on the target architecture (determined in build.rs).

Currently, chunk size is based only on native register size. ByteSet should expanded be to use 64-bit chunks on 32-bit targets with meaningful 64-bit instructions.

Consider (and benchmark!):

• arm with neon target feature

The PartialOrd and Ord implementations should take advantage of the internal representation to improve performance.

The std::bitset<256> type in C++ is comparable to ByteSet.

Considerations:

• FFI overhead
  • No inlining

I think this is worth implementing and adding to #1.