Why does string.replace not return an iterator?

[Marcel Mueller]

The iterator based erase and insert functions of std::string return an
updated iterator because any modifying function invalidates all iterators.
string.replace does not. This makes it more complicated and badly
readable to apply multiple replacements to a string.
Why this asymmetry?


Marcel

[David LaRue]

Marcel Mueller <news.5...@spamgourmet.org> wrote in
news:tjunkh$2oqmq$3...@gwaiyur.mb-net.net:

Perhaps you could create one and submit it for ratification. At the very
least it would help your coding.

[Marcel Mueller]

Am 03.11.22 um 00:38 schrieb David LaRue:

>> The iterator based erase and insert functions of std::string return an
>> updated iterator because any modifying function invalidates all
>> iterators. string.replace does not. This makes it more complicated and
>> badly readable to apply multiple replacements to a string.
>> Why this asymmetry?
>

> Perhaps you could create one and submit it for ratification.

No idea how to do so.

And since it is a potentially breaking change for existing code, it
probably cannot be done easily.

> At the very least it would help your coding.

In fact I already wrote my own function with pointer arithmetic to come
around this restriction.

I just wondered because replacing string parts not recursively is a not
that uncommon requirement.


Marcel

[Andrey Tarasevich]

Um... On the one hand, `std::string::replace`'s return value is not
vacant. It returns a reference to `*this`. So, it is natural to assume
that the opportunity to return an iterator wasn't simply ignored, but it
simply lost the debate against the idea to return `*this`. The latter
allows one to make chained call to `replace`, which was probably
considered more valuable.

On the other hand, there are several such "asymmetries" in the design of
standard containers. The same applies to various `push_back/push_front`
methods. In their case the return value is `void`, i.e. the opportunity
to return an iterator (or a reference?) was there all the time without
any other contenders. `emplace_back/emplace_front` took that
opportunity, except that they return references, not iterators.

--
Best regards,
Andrey.

[Öö Tiib]

On Friday, 4 November 2022 at 00:21:38 UTC+2, Andrey Tarasevich wrote:
> On 11/2/2022 2:32 PM, Marcel Mueller wrote:
> > The iterator based erase and insert functions of std::string return an
> > updated iterator because any modifying function invalidates all iterators.
> > string.replace does not. This makes it more complicated and badly
> > readable to apply multiple replacements to a string.
> > Why this asymmetry?
>
> Um... On the one hand, `std::string::replace`'s return value is not
> vacant. It returns a reference to `*this`. So, it is natural to assume
> that the opportunity to return an iterator wasn't simply ignored, but it
> simply lost the debate against the idea to return `*this`. The latter
> allows one to make chained call to `replace`, which was probably
> considered more valuable.

The replace is family of 9 overloads. While that makes sense
to chain position and count-based replaces the OP discusses specifically
iterator-based overloads of replace. How you chain those?

[Marcel Mueller]

Am 04.11.22 um 01:40 schrieb Öö Tiib:

> The replace is family of 9 overloads. While that makes sense
> to chain position and count-based replaces the OP discusses specifically
> iterator-based overloads of replace. How you chain those?

Exactly. This is impossible since every iterator gets invalidated on the
first invocation. Any chanied call to an iterator based function is UB.


Marcel