If you ask me, trying to get feature parity with Python seems one of the worst justifications to implement a feature, actually it is a good reason not to implement a feature.

Hear me out:

You should only try to add features to the language after you have done proper study of the problem, and you have produced a well tough ought reason as to why things should be done the way you suggest, the reason is never going to be “because some other language does it”. It can be “this other language does, here’s the reason why they do it, it’s a good thing and we can use that in C++”, but my takeaway is going to be the “good reason why” and I couldn’t care less about “that this other language does it”, because maybe they do it and it is a bad idea.

If your reason is because “I like python”, then that means you haven’t done a proper study, you don’t know if this is the best solution or even if it is good solution, because had you done that, we would have that reason in the paper and not “python did it”.

Having said that:

1. Feature parity with std::basic_string_view is missing, and I would argue that std::basic_string_view is by far much more important than std::basic_string
2. string.slice(being, end) is identical too string_view(string).substr(begin, end - begin), and the later has the added benefit of the explicit cast to string_view signaling to the user what would be the resulting expectation without reading documentation, accepting that what you are getting in return is a view and not for example a copy of a section of a string (which is what I would naturally expect from basic_string).

I’m not saying that this is bad, there’s some precedent to work with things in terms of (begin, end) as opposed to (begin, size), although due to implementation details the second may actually be better in this case.

But the justification needs more work, and the paper isn’t proposing a feature that would allow us to do something that we cannot easily do already.

Br,

Tiago