Re: Interest in a Unicode library for Boost?

From: Gavin Lambert (boost_at_[hidden])
Date: 2019-10-29 23:26:29

On 30/10/2019 05:11, Zach Laine wrote:
>     - pattern if (x == npos) is now so common that is imho important to
>     preserve it
> 
> The std::string/std::string_view API is the only place in the STL where 
> the algorithms do not return the end of the half-open input range on 
> failure.  That's really wonky.  I don't care about preserving it.

Returning end of range on failure is incredibly inconvenient (for the 
consumer; granted it's usually more convenient for the algorithm 
implementer), and I'd be happier if STL algorithms didn't do that either.

I see that as an unfortunate consequence of using generic iterators as 
input parameters and return types, and not an otherwise desirable design 
choice.

(ie. the STL algorithms do it because they couldn't do anything better. 
string doesn't do it because it can do something better [since it knows 
the iterator type and class, and can consequently choose to return 
something other than an iterator].)

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

While I too dislike policy parameters as a general rule -- especially 
defaulted policy parameters, since APIs have a tendency to only 
implement one and not all (see: how many libraries use std::string 
instead of being templated on std::basic_string, or use std::vector<T> 
instead of being templated on an allocator)...

Technically speaking, a different policy parameter does form a different 
type name and thus "types with different invariants should have 
different names" is satisfied.