Would it make sense to have a proper "boolean" type?

[cousteaulecommandant]

Disclaimer: this proposal only makes sense if arrays of boolean values are suspected to be needed in real world applications; if they're never really used, it can be ignored and closed.

Although there are already two boolean types, true and false, I think a proper bool type that can take either of the two values could be useful in the case of fixed-type arrays of boolean values. I propose two new boolean types (in addition to the already existing T and F):

• byte-wide bool: B followed by a byte with value 0x00 or 0x01 to indicate false or true respectively.
• bit-wide bool: b followed by a single left-aligned bit, padded with zeros to the end of the byte. In principle this is identical to using B but with 0x80 instead of 0x01, but in the case of type & count optimized arrays it could allow storing a lot of bit fields in a short space.

Although these types are redundant given that T and F are already a thing, there may be some advantages:

• Software optimizations: it may be useful for a software implementation to know that a field is an array of boolean values before reading all of it (for example for allocating memory), and currently there's no way of specifying such a thing. Additionally, 0x00 and 0x01 map directly to false and true in C, so there would be no need to parse these values (even if the parsing would've been minimal anyway) and they could be copied directly.
• Compacity: an array of bit-wide bools could theoretically fit up to 8 boolean values per byte.
• It serves as an alternative for a "raw binary bit stream" type, for example for embedding files into UBJSON documents (although this is not part of JSON anyway). (On second thought, this can also be implemented as an array of uint8 already.)

Downsides are:

• The UBJSON specification changes, so if it's already considered to be in a stable state, introducing new types is not a feasible option.
• A redundant type is added. On its own, B has the same functionality as T and F and uses twice as much space, so it's pretty much useless outside of the field of "fixed type values".
• The parser becomes more complex due to the b type, as it has to do bitwise operations rather than just dealing with bytes.
• I can't really think of a real life application where this would be useful other than "raw binary data" (which could be implemented as an array of uint8 anyway) and bitmap images.

What do you think? Would these two types (or one of them at least) be useful?

[AnyCPU]

@cousteaulecommandant there should be a good-real-world example. I think the T & F are good enough. There are no reasons to add the B type into the spec for me.

@rkalla What do you think?

[Steve132]

The main advantage I can think of is for strongly typed arrays we can correctly associate a sequence of booleans without making them T/F