On 7 December 2022 18:51:40 GMT, Jason McKesson via Std-Discussion <std-discussion_at_[hidden]> wrote:
>On Wed, Dec 7, 2022 at 1:33 PM Daniel Krügler via Std-Discussion
><std-discussion_at_[hidden]> wrote:
>>
>> Am Mi., 7. Dez. 2022 um 19:22 Uhr schrieb Lénárd Szolnoki via
>> Std-Discussion <std-discussion_at_[hidden]>:
>> >
>> > Hi,
>> >
>> > On 7 December 2022 17:12:17 GMT, Giuseppe D'Angelo via Std-Discussion <std-discussion_at_[hidden]> wrote:
>> > >Hello,
>> > >
>> > >Il 07/12/22 16:19, Kilian Henneberger via Std-Discussion ha scritto:
>> > >> But if `std::string::const_iterator` is a class type, then the first overload is a better match and will be called.
>> > >
>> > >This is https://cplusplus.github.io/LWG/issue84 .
>> >
>> > What is "23.1.1.9 (the "do the right thing" fix)" the issue refers to?
>>
>> Checking my 1998 standard, this most likely refers to paragraph 9 in
>> 23.1.1 [lib.sequence.reqmts]:
>>
>> "For every sequence defined in this clause and in clause 21:
>> [...]
>> — the member functions in the forms:
>> template <class InputIterator> // such as insert()
>> rt fx1(iterator p, InputIterator f, InputIterator l);
>> [...]
>> shall have the same effect, respectively, as:
>> fx1(p,
>> static_cast<typename X::size_type>(f),
>> static_cast<typename X::value_type>(l));
>> [...]
>> if InputIterator is an integral type.
>> "
>
>Note that the modern form of this is found in [sequence.req]/13.2, and
>it says basically the same thing, using more modern idioms.
>Specifically, if the InputIterator type is not *actually* an
>InputIterator, then those overloads do not participate in overload
>resolution.
>
>So basically, it is NAD because the issue was resolved in a different way.

I wouldn't say that the issue is resolved, the original issue remains potentially ambiguous, where str.insert(0, size, ch) is called. Now this InputIterator overload is not even involved.