The rationale is this: All the other character types in C++ -- every one -- advertises that it is a certain Unicode encoding (char{8,16,32}_t) or is specifically designed to hold Unicode code points (wchar_t). char is the only exception to this.
What about unsigned char?
As for turning off Unicode for charN_t and wchar_t, do you have a compelling use case for that? It seems very unlikely to me.
From what I saw in other reviews, I think it's more about not needing it (and not wanting to pay the price) than about needing it not to exist.
hana::tuple has one great feature that std::tuple does not: operator[]. It is *so* much nicer to use that than std::get<>(), that it makes it worth all the trouble. I have been using Parser to write parsers for a few years now, and I'm telling you, don't sleep on op[].
Is there a case where this makes it much more convenient than std::get? Is there are reason why it being a peer-dependency wouldn't work? (Just letting it generically populate a tuple type like it does for other types) Also the other rationale I included.
Telling such a usual user to read the code to reverse engineer how it should be done is no good. Especially because the number of concepts and requirements involved is probably not much larger than what's already documented.
I don't really expect too many users to do this, and it was never a design goal to make this easy to do. I sort of begrudgingly added that section at all because Andrzej was hounding me about it.
I definitely would do this if using the library. I don't know if it's the same rationale as Andrzej's, but I would avoid using the library if I knew I would be stuck if I reached a corner where I couldn't find a way to represent a rule by composing existing rules. Also the other rationale I included.
if people start writing a lot of them.
Yes. I would start writing them from day 0. So you can count on me.