Files pack.hpp, type_traits.hpp, unbounded_shift.hpp, endian_shift.hpp are copied into all the repos. I'm not even sure which repo is supposed to have these file, but they use the same #ifdef-s, which means that we need to keep them identical, otherwise it's not clear which one will be used in the crypto3-zk project. (many of them will get included from different sources)

In case of the library gets used as a standalone one, it need for the https://github.com/BoostCMake/cmake_modules.git to be present as submodule.

Base58 codec seems to be broken.

Return-value converter seems to work now only for explicit type-initialized variables:

std::string out = encode<codec::base64>(in.begin(), in.end());

The same construction fails if the variable was initialized earlier:

std::string str = "123";
str = encode<codec::hex>(str.begin(), str.end());

This leads to ambiguous operator= selection.

Range adaptor implementation would allow to use encoding as follows:

std::string src = "abc", res = src | encoded<bech<32>>;

Base58 encoding tests are obviously required to be implemented.

Currently the library is highly dependent on C++17 inline variables feature. This requirement should be dropped down at least to C++11.

Currently only range-to-iterator or iterator-to-iterator interfaces are supported. But no range-to-range algorithm is available.

CocoaPods podspec implementation would allow to put together iOS & macOS SDK.

Inspectable concept is required for recursive type marshalling support to be done. Example of such a requirement - generic type serialization to Integral concept-complying type (or sequence of ones).

Implementation from language-specific constructions separation allows to implement FFI to codecs itself with no redundant preprocessing.

Algorithm-like interface looks fine, but the standard proposes one more way to work with the data streams - iostream library. Adoption should be considered.

Pack was rewritten in hashes and requires an update here.

Documentation along with tutorials and reference implementation is required. Note, this should be embeddable into a parent project documentation aggregator.

Current testing implementation relies on runtime initialization of pre-generated data in runtime data structures.

This requires to be refactored to file-driven and random-generated data sources.

Commonly used functions (e.g. pack or exploder/imploder) are duplicated in various crypto3 libraries. Factoring them out to become a detail directory of the whole crypto3 suite seems legit.

Bech32 is a string encoding format.

The output consists of a human-readable part (alphanumeric), a separator character (1), and a base32 data section, the last 6 characters of which are a checksum.

For more information, see BIP-0173.

CRYPTO3_MP_WORD_BITS is now being defined during CMake configuration process. This way is not a portable one. This macro definition has to be moved to Boost.Predef library. Currently implemented in boostorg/predef#107 and boostorg/predef#108.