On Fri, May 3, 2024 at 11:21 AM Giuseppe D'Angelo via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Il 03/05/24 15:31, Rhidian De Wit via Std-Proposals ha scritto:
> >
> > I indeed proposed this because I found myself having to do this trivial
> > functionality often enough where I wondered why it wasn't part of the
> > /std::string/ toolset. I understand the /std::string/ API size worries
> > though, but I don't see why we could add 2 small functions to it.
> > However, I realize that this is the exact mindset that leads to such
> > massive api's, aka "just one more function won't make a difference...".
>
> I am completely unconvinced that std::string has a rich interface. Do we
> want to compare QString, juce::String, etc. to it? Where's my replace(),
> trim(), split(), string builders, Unicode conversions, ...?
>
> Please, add as much convenience as possible for the end-user. A
> minimalistic API for vocabulary classes helps the _implementors_, not
> the _users_ (the 99.9999%).

Yes, `std::string` does not really have a "rich" interface; it has a
*large* interface. The problem is that this large interface is mostly
bad. But you can't simply get rid of most of it because code exists
that depends on it. And adding more to it makes it harder for users to
find good interfaces among the tons of bad ones.

It's an intractable problem owing to decades of cruft caused by
adopting a poorly-designed string type to begin with.

That being said, many of the functions you cite require the string to
have specific knowledge of the meaning of what it stores. `trim` needs
to know what a "space" is; Unicode operations require knowing that the
string is encoded in accord with Unicode and what that encoding is.
`std::string`, due to being very old, doesn't have that information.