Re: Fixed String review

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-12-02 16:58:19

On Mon, Dec 2, 2019 at 3:07 AM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> wt., 26 lis 2019 o 18:34 Vinnie Falco via Boost <boost_at_[hidden]>
> napisał(a):
>
> > On Tue, Nov 26, 2019 at 8:31 AM Phil Endecott via Boost
> > <boost_at_[hidden]> wrote:
> >
> > > You've chosen to return a string_view from substr().  I think that's
> > > a bit dangerous; code that does "auto a = s.substr(...)" could end
> > > up with a dangling view when s is a fixed string; this makes it
> > > more difficult than it should be to migrate from one string type
> > > to another, or to write generic code.
> >
> > Again we have to refer to the purpose of the container. People are
> > using this for performance, the very last thing they want from
> > substr() is to receive a copy. Users can opt-in to making a copy if
> > they want, by constructing a new static_string from the string view
> > returned by substr. If we go with your suggestion, no one can opt out
> > of copies.
> >
>
> Even if this is a valid design choice when considered in separation, it is
> clearly in conflict with the goal of being a drop-in replacement for
> std::string. It looks like the library is aiming at being a drop-in
> replacement for some subset of usages of std::string. It would be
> beneficial to outline this subset clearly in the initial sections of the
> documentation.
>

+1.  FWIW, I find "this is a drop-in replacement" to be a typically
unattainable goal for anything that is not based on some kind of
polymorphism (compile- or runtime).  That is, the polymorphic drop-in
mechanism only cares about a subset of API and/or behavior.

Zach