On 26.10.19 18:41, Zach Laine via Boost-users wrote:
> On Sat, Oct 26, 2019, 12:41 AM Rainer Deyke via Boost-users <
> boost-users@lists.boost.org> wrote:
>
>> On 26.10.19 03:11, Zach Laine via Boost-users wrote:
>>> If you care about portable Unicode support, or even addressing the
>>> embarrassment of being the only major production language with next to no
>>> Unicode support, please have a look and provide feedback.
>>
>> I can't see myself using the string layer at all.  My codebase is too
>> deeply linked to std::string, as is the standard library, and a fair
>> number of third-party libraries I am using.  Also, the primary advantage
>> of the string layer seems to be a narrower interface, which is not an
>> advantage at all to me as a user.
>
>
> It is also a place to experiment with things like ropes and string
> builders.  I would like to standardize both, and I need a string that
> actually interoperates with those to show how they might work.
>
> std::string::find may be bad design,
>> but it doesn't hurt me, it just makes finding elements in a string
>> slightly more convenient.
>
> But it does hurt newcomers to the language, who must learn a slightly
> different API for string and string_view, and static_string and
> fixed_string if we get those.  It also hurts the standardization effort to
> review all those APIs.  You cannot use the std::string search algorithms on
> spans and other ranges or views either.

The issue isn't if your string is better than std::string.  The issue is
if your string provides of an improvement to justify switching from
std::string, after the time and effort spent learning std::string is
already spent.  If I want to not use std::string::find, I can simply not
use it.

> Returning -1 instead of the end index it's also pretty horrible.

Not sure I agree.

auto pos = some_long_expression().find('.');

// Clear, simple, obvious:
if (pos == std::string::npos) {
   ...
}

// Less clear, and I have to either evaluate the same expression twice
// or use an additional variable, possibly making an extra copy of the
// string in the process.
if (pos == some_long_expression().size()) {
}

> If convenience is so paramount, why don't we add member sort () to vector?

Because it would be inconvenient to change existing code from std::sort
to std::vector::sort, but also because my entire codebase contains only
8 calls to std::sort and at least two orders of magnitude as many calls
to std::string::[r]find.

For what it's worth, if I were back in the C++98 standards committee, I
would vote against the inclusion of std::string::find.  But that's not
the current situation.