On Sat, Oct 26, 2019 at 3:01 PM Rainer Deyke via Boost-users < boost-users@lists.boost.org> 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@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.
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