Re: Interest in a Unicode library for Boost?

From: Leon Mlakar (leon_at_[hidden])
Date: 2019-10-30 09:56:22

I'm reposting this - by mistake I've used "Reply" instead of "Reply To 
List" button. I apologize for the inconvenience.
>
>     - for the sake of completeness the normalization type used at the
>     text
>     level ought to be a policy parameter; although I do understand your
>     arguments against it I think it should be there even at the cost of
>     different text types being inoperable without conversions
>
>
> I disagree.  Policy parameters are bad for reasoning.  If I see a 
> text::text, as things currently stand, I know that it is stored as a 
> contiguous array of UTF-8, and that it is normalized FCC.  If I add a 
> template parameter to control the normalization, I change the 
> invariants of the type. Types with different invariants should have 
> different names.  To do otherwise is a violation of the single 
> responsibility principle.

Okay, the policy or not the policy was not my point ... it was to allow 
for different underlying normalizations. Granted, it may only be 
important to (a few) corner cases where input and/or output 
normalizations are given, and your assessment that it may not be worth 
the effort is reasonable ... unless you are aiming towards adding to the 
standard. Then the completeness imho becomes more important.

Frankly, I'm not proficient enough in the meta-programming to make a 
strong case either for policy parameter or for explicit types/templates. 
I just happen to prefer the policy based approach.

>     - at the text level I'm not sure I'm willing to cope with different
>     fundamental text types; I just want to use boost::text::text, pretty
>     much the same as I use std::string as an alias to much more complex
>     class template; heck, even at the string layer I'd probably prefer
>     rope/contiguous concept to be a policy parameter to the same type
>     template.
>
>
> That would be like adding a template parameter to std::vector that 
> makes it act like a std::deque for certain values of that parameter.  
> Changing the space and time complexity of a type by changing a 
> template parameter is the wrong answer.
No, that is not making the std::vector to act as std::deque - the text 
would still remain the text and act as a text, with the same interface. 
It's more like FIFO implementation using either std::vector or 
std::dequeu for its store - since in both cases the FIFO has the same 
interface and functionally behaves the same, I really don't want two 
distinct types. The type template with the parameter that makes the 
choice between the underlying storage seems much more natural to me.
>
>     - views should be introduced as views and not mixed with
>     rope/contiguous
>     fundamental types
>
>
> That does not sound like what I want either, but I don't know what 
> this refers to.  Could you be specific?
>
Well, I'll have to think more about it ... it struck me that the docs 
often mention X and X_view in the same sentence, and you have to go 
elsewhere to learn that one is owning and the other isn't. I hope I'll 
find some time in the next days and come back on this.

Cheers,

Leon