wt., 26 lis 2019 o 18:34 Vinnie Falco via Boost
On Tue, Nov 26, 2019 at 8:31 AM Phil Endecott via Boost
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. Regards, &rzej;