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.