Re: Interest in a Unicode library for Boost?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-10-26 20:24:51

On Sat, Oct 26, 2019 at 3:01 PM Rainer Deyke via Boost-users <
boost-users_at_[hidden]> wrote:

> 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_at_[hidden]> 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.
>

Fair enough.  Like I said, the string stuff was originally added to explore
what a std2::string might look like.  As of this writing, that's not really
a thing that will happen.

Zach