- 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.
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.- 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.
- 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