My apologies, I accidentally uploaded an older version, the correct version
can be found in the attachments:

Op di 26 mrt 2024 om 09:55 schreef Rhidian De Wit <rhidiandewit_at_[hidden]>:

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

-- 
Rhidian De Wit
Software Engineer - Barco