Hi everyone,

I've updated the proposal:
- I've written down some more motivation with an example
- I've added *.subview()* to *std::basic_string_view*

Thanks for all of the discussion so far, it's proven to be very interesting
and useful!

Have a nice day,

Op di 19 mrt 2024 om 23:16 schreef Tiago Freire <tmiguelf_at_[hidden]>:

>
>
> 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
>

-- 
Rhidian De Wit
Software Engineer - Barco