Distinct Bool Type

[ax3l]

Why is this feature important?

Many users are not aware of the intricacies with boolean types, which stem from the pre-C99 days and are not relevant in today's programming languages of many projects (C++/Python).

Thus, users are often confused about a lack of support for the bool type when using ADIOS2 directly or middleware like openPMD-api. A typical use-case for boolean types are "masks" to mark particle data.

What is the potential impact of this feature in the community?

Adding a distinct bool type would simplify implementations and increase usability.

Is your feature request related to a problem? Please describe.

Existing openPMD implementation in openPMD-api, as used in PIConGPU and WarpX.

Describe the solution you'd like and potential required effort

We would like a distinct type for bool.

We are ok to map this type transparently to any other byte-like type in the C-api or to even not handle bool at all for the C bindings. In case the C-bindings require C99 or newer, _Bool from stdbool.h can be used.

Describe alternatives you've considered and potential required effort

In the original PIConGPU ADIOS1 implementation as well as the new openPMD-api library, we use a convention to map bool types to adios_unsigned_byte/unsigned char/uint8_t and stores an additional attribute with each boolean attribute and variable. This increases the meta-data overhead and I/O logic, which is often needless boilerplate.

Also, we need to maintain this convention in openPMD-standard for people that write or read to our bool types, e.g. via the ADIOS Python or Fortran bindings.

Additional context

HDF5 also has no bool type, but there a common convention from h5py can be applied by using user-defined enums with specific labels. (Values 1 are marked with a TRUE label and values 0 are marked with a FALSE label.) Adding enums to ADIOS would be a bit too sophisticated for what we want to achieve (and then still requires a convention for the labels of the enum).

Carbon Copies

@franzpoeschel

[williamfgc]

I'd just be careful with std::vector<bool> it's not a standard container as it holds bits not bytes. See here.

[pnorbert]

Well, yes, that's the reason why adding bool into the list of supported types is not possible. The Variable class does not compile because the data pointer is unusable on a vector of bools.

[ax3l]

Hm, yep it would be good to avoid std::vector<T> for internal data storage and use something like a unique_ptr or a span on it.

[williamfgc]

yup, to make things worse sizeof(bool) is not defined, see here.