|
Boost : |
From: Alan de Freitas (alandefreitas_at_[hidden])
Date: 2024-02-29 15:01:21
>
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk