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.