Hi,

- They make the huge interface that is std::string even bigger
>

This would, in my opinion, be indeed the greatest disadvantage, since
*std::string* is indeed massive as-is, however, I do find myself often
enough having to type *std::string::substr(0, N) *where I think it's worth
the extra functionality.

- They offer a good looking but inefficient way to express starts_with and
> ends_with on std::string - s.first(5) == "abcde". The paper is so terse
> though that I don't know what the return value of first() would be on
> std::string - does it return a string or a string_view? If it returns a
> string it's inefficient. If it returns a string_view it's inconsistent with
> the rest of std::string.
>

I think *.first()* and *.last()* should return their respective type (
*std::string* in case of *std::string::first()* and *std::string::last() *and
vice versa with *std::string_view*).
This for the purpose that it's indeed inconsistent with the rest of
*std::string* if it were to return a view instead of another string. I
don't think the inefficiency holds much merit here, since
*std::string::substr(0,
N)* has the same downside, and it's an acceptable downside.
You can already get a non-owning view of the string by first constructing a
*std::string_view* and then calling *.first()*.

- How often would these functions be used? The functionality is already
> captured and used often from within substr, and special-casing is fine if
> there is a wide enough use for this. I don't know the numbers but would
> need to know that it's serving a wide enough use case. I will admit that I
> recognize writing `substr(0, X) and substr(X, str.size() - X) often enough
> to know that I myself would have some use for them, but that doesn't
> trivially extend to the whole community.
>

I indeed proposed this because I found myself having to do this trivial
functionality often enough where I wondered why it wasn't part of the
*std::string* toolset. I understand the *std::string* API size worries
though, but I don't see why we could add 2 small functions to it.
However, I realize that this is the exact mindset that leads to such
massive api's, aka "just one more function won't make a difference...".

Can’t first() and last() be free functions?
> Then they would not increase the surface area of std::string, and they
> would work with any sequence.
>

This could be indeed a interesting compromise, a *std::first()* and
*std::last()* for all contiguous containers (*std::string*, *std::vector* and
*std::array*).

Sincerely,

Op di 30 apr 2024 om 09:48 schreef Peter Bindels <dascandy_at_[hidden]>:

> Let me first say I like the basic premise.
>
> + It resembles the functions starts_with and ends_with that we recently
> (2020) got
> + They make code easier to read and write.
> - They make the huge interface that is std::string even bigger
> - They offer a good looking but inefficient way to express starts_with and
> ends_with on std::string - s.first(5) == "abcde". The paper is so terse
> though that I don't know what the return value of first() would be on
> std::string - does it return a string or a string_view? If it returns a
> string it's inefficient. If it returns a string_view it's inconsistent with
> the rest of std::string.
> - How often would these functions be used? The functionality is already
> captured and used often from within substr, and special-casing is fine if
> there is a wide enough use for this. I don't know the numbers but would
> need to know that it's serving a wide enough use case. I will admit that I
> recognize writing `substr(0, X) and substr(X, str.size() - X) often enough
> to know that I myself would have some use for them, but that doesn't
> trivially extend to the whole community.
>
> Thanks for the paper! I do hope you can make it into a full paper with the
> information above, and I hope to see you at a standards meeting!
>
> Peter
>
>
>
>
>
> On Tue, Apr 30, 2024 at 9:17 AM Rhidian De Wit via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello everyone,
>>
>> I've finally had some time to write a small proposal for a small addition
>> to std::string and std::string_view.
>> I will later add the proposed wording, but I'd already be appreciative of
>> whatever comments anyone might have.
>>
>> Sincerely,
>> --
>> Rhidian De Wit
>> Software Engineer - Barco
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>

-- 
Rhidian De Wit
Software Engineer - Barco