On Tue, 10 Jan 2023 at 22:00, Lénárd Szolnoki via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Tue, 10 Jan 2023 17:47:38 +0000
> Edward Catmur via Std-Discussion <std-discussion_at_[hidden]>
> wrote:
>
> > On Tue, 10 Jan 2023 at 17:05, Brian Bi <bbi5291_at_[hidden]> wrote:
> >
> > >
> > >
> > > On Tue, Jan 10, 2023 at 11:24 AM Edward Catmur via Std-Discussion <
> > > std-discussion_at_[hidden]> wrote:
> > >
> > >>
> > >>
> > >> On Tue, 10 Jan 2023 at 15:57, language.lawyer--- via
> > >> Std-Discussion < std-discussion_at_[hidden]> wrote:
> > >>
> > >>> > I would like an example of a function call to an overloaded
> > >>> > function, where the most viable function is determined by the
> > >>> > rules listed from [over.ics.rank]/4.4.5 to
> > >>> > [over.ics.rank]/4.4.8:
> > >>> >
> > >>> > https://timsong-cpp.github.io/cppwp/n4868/over.ics.rank#4.4.5
> > >>> >
> > >>> > These are four different tie-breakers for ranking standard
> > >>> > conversions from different source types, assuming the following
> > >>> > class hierarchy:
> > >>> >
> > >>> > struct A {}; struct B : C {}; struct C : B {};
> > >>> >
> > >>> > (4.4.5) conversion of B* to A* is better than conversion of C*
> > >>> > to A*, (4.4.6) binding of an expression of type B to a
> > >>> > reference to type A is better than binding an expression of
> > >>> > type C to a reference to type A, (4.4.7) conversion of B::* to
> > >>> > C::* is better than conversion of A::* to C::*, and
> > >>> > (4.4.8) conversion of B to A is better than conversion of C to
> > >>> > A.
> > >>> >
> > >>> > The note says that these are only used for tie-breakers in the
> > >>> > second conversion sequence of user-defined conversions:
> > >>> >
> > >>> > https://timsong-cpp.github.io/cppwp/n4868/over.ics.rank#note-1
> > >>>
> > >>> I think it is just a wrong Note.
> > >>> CD2 (November 96
> > >>>
> https://www.open-std.org/jtc1/sc22/wg21/docs/wp/html/cd2/over.html#over.ics.rank
> )
> > >>> Note was saying:
> > >>> > [Note: it is necessary to compare conversions with different
> > >>> > target types in the context of an initialization by
> > >>> > user-defined conver- sion; see _over.match.best_. ]
> > >>>
> > >>> Which also seems not 100% correct (incomplete?), because it
> > >>> mentions (only?) target, and not source types.
> > >>>
> > >>> The next WP (Oct'97
> > >>>
> https://www.open-std.org/jtc1/sc22/wg21/docs/wp/html/oct97/over.html#over.ics.rank
> )
> > >>> Note gained its current (defective) wording.
> > >>>
> > >>> (The bullets themselves have been added by
> > >>> https://www.open-std.org/JTC1/sc22/wg21/docs/papers/1995/N0661.asc)
> > >>>
> > >>> So, ecatmur's example seems to be relevant here, except that the
> > >>> Note is not about the second standard conversion sequence after
> > >>> different user conversion functions, but about
> > >>>
> https://timsong-cpp.github.io/cppwp/n4868/over.match.best#general-2.2
> > >>>
> > >>
> > >> Ah. So, currently, the Note says:
> > >>
> > >> > Compared conversion sequences will have different source types
> > >> > only in
> > >> the context of comparing the second standard conversion sequence
> > >> of an initialization by user-defined conversion (see
> > >> [over.match.best]); in all other contexts, the source types will
> > >> be the same and the target types will be different.
> > >>
> > >> Whereas [over.match.best.general]/2.2 says:
> > >>
> > >> > ... the context is an initialization by user-defined conversion
> > >> > (see
> > >> [dcl.init], [over.match.conv], and [over.match.ref]) and the
> > >> standard conversion sequence from the return type of F1 to the
> > >> destination type (i.e., the type of the entity being initialized)
> > >> is a better conversion sequence than the standard conversion
> > >> sequence from the return type of F2 to the destination type ...
> > >>
> > >> Would it make sense to amend the latter to mention the second SCS?
> > >> i.e.,
> > >> > ... the context is an initialization by user-defined conversion
> > >> > (see
> > >> [dcl.init], [over.match.conv], and [over.match.ref]) and the
> > >> <ins>second</ins> standard conversion sequence <ins>of ICSj(F1)
> > >> (i.e., that</ins> from the return type of F1 to the
> > >> <del>destination type (i.e.,</del> the type of the entity being
> > >> initialized) is a better conversion sequence than the
> > >> <ins>second</ins> standard conversion sequence <del>from the
> > >> return type of F2 to the destination type</del><ins>of
> > >> ICSj(F2)</ins> ...
> > >
> > > I think if we need to clarify it, we should just add a note.
> > > Changing normative wording always risks unforeseen consequences.
> > >
> >
> > Ah, Well, should we change the offending Note (to [over.ics.rank])
> > then?
> >
> > > Compared conversion sequences will have different source types
> > > only in
> > the context of <del>comparing the second standard conversion sequence
> > of</del> an initialization by user-defined conversion<ins>,
> > specifically when comparing the standard conversion sequence from the
> > return type of a viable function to the destination type</ins> (see
> > [over.match.best]); in all other contexts, the source types will be
> > the same and the target types will be different.
>
> I might have found a case where no user-defined conversions are
> involved:
>
> struct A {
> void foo();
> };
>
> struct B : A {
> using A::foo;
> void foo(int);
> };
>
> struct C : B {};
>
> void f(void (C::*)()); // 1
> void f(void (C::*)(int)); // 2
>
> int main() {
> // if conversion from void (B::*)(int) to void (C::*)(int)
> // is better than void (A::*)() to void (C::*)()
> // then the second overload must be called
> f(&B::foo);
> }
>
> I think https://eel.is/c++draft/over.ics.rank#4.5.7 applies, although
> only gcc implements this.
>
> https://godbolt.org/z/7corz5539
>
> Anyway, if this applies, then the note wrongly states that these only
> apply in the context of user-defined conversions.
>

Oh, brilliant. OTOH, where the pointer is used directly, there's full
agreement:

struct A { void foo(); };
struct B : A { using A::foo; void foo(); };
struct C : B {};
void (C::*p())() { return &C::foo; } // B::foo

But not if we write it like this; only MSVC accepts:

struct A { void foo(); };
struct B : A { void foo(); };
struct C : B { using A::foo; using B::foo; };
void (C::*p())() { return &C::foo; } // B::foo (MSVC only)

Do you have any thoughts on this?

And there's another issue with this, though;
https://eel.is/c++draft/over.over#2 says:

> ... a non-template function with type F is selected for the function type
FT of the target type if F (after possibly applying the function pointer
conversion ([conv.fctptr])) is identical to FT.
[Note: That is, the class of which the function is a member is ignored when
matching a pointer-to-member-function type. — end note]

This Note is problematic; what is meant by "matching"? This is too early
for overload resolution, but looking at the context in which it was added
https://cplusplus.github.io/CWG/issues/1153.html it's clear (to me) that
instead this should read "That is, the class of which the function is a
member is ignored when <del>matching</del><ins>selecting functions
for</ins> a pointer-to-member-function type.".

Also, we may select member functions that cannot be converted to the target
pointer to member function type:

struct A { void foo(); };
struct B : A { using A::foo; void foo(); };
struct C : B {};
struct D : C { using B::foo; void foo(); };
void (C::*p())() { return &D::foo; }

Unfortunately, everyone rejects this, but IMO this should be valid; it
should remove D::foo from the overload set before ranking. So I would have
[over.over]/2 refer to [conv.mem] and amend the Note:

> ... a non-template function is selected if the type of a pointer to the
function can be converted to the target type via a standard conversion
sequence consisting only of pointer-to-member conversions ([conv.mem]) and
function pointer conversions ([conv.fctptr]). [Note: The function type of
the target type must thus be identical to the function type of the
function. --end note]

In any case, we now may have a set of (pointer to member) functions that
may be ranked according to [over.ics.rank]/4.5.7. But [over.over]/5 doesn't
tell us to do this, or indeed when to do this!

If we give B::f unsatisfied constraints (as a function template
specialization), everyone (gcc, clang and MSVC, that is - I don't have an
EDG with concepts) is happy to select A::f:

struct A {
    template<int...> int f();
};
struct B : A {
    using A::f;
    template<int...> int f() requires(false);
};
int (B::*p())() { return &B::f; }

But if we make B::f a non-template function with unsatisfied constraints,
MSVC rejects:

template<int...> struct A {
   int f();
};
template<int...> struct B : A<> {
   using A<>::f;
   int f() requires(false);
};
int (B<>::*p())() { return &B<>::f; }

If we make B::f a function template specialization and A::f a non-template
function, everyone except EDG prefers A::f:

struct A {
    int f();
};
struct B : A {
    using A::f;
    template<int...> int f();
};
int (B::*p())() { return &B::f; } // A::f (gcc, clang, MSVC), B::f<> (EDG)

If we make A::f and B::f function template specializations with A::f more
constrained than B::f, gcc, clang and MSVC prefer A::f:

struct A {
    template<int...> int f() requires(true);
};
struct B : A {
    using A::f;
    template<int...> int f();
};
int (B::*p())() { return &B::f; } // A::f<> (gcc, clang, MSVC)

But if we make A::f and B::f non-template functions with A::f more
constrained than B::f, gcc and clang error while MSVC prefers B<>::f:

template<int...> struct A {
    int f() requires(true);
};
template<int...> struct B : A<> {
    using A<>::f;
    int f();
};
int (B<>::*p())() { return &B<>::f; } // &A<>::f (more constrained) or
&B<>::f (better pointer-to-member)?

For consistency with [over.match.best.general]/2, which
puts [over.ics.rank] (at 2.1) ahead of [temp.constr.order] (at 2.6), I
would select B::f in all cases and amend [over.over]/5:

> All functions with associated constraints that are not satisfied
([temp.constr.decl]) are eliminated from the set of selected functions.
<ins>Any given member function MF1 is eliminated if the set contains a
second member function MF2 such that the standard conversion sequence from
the type of a pointer to MF2 to the target type is better than the standard
conversion sequence from the type of a pointer to MF1 to the target type.
[Note: when ranking such standard conversion sequences, only
pointer-to-member conversions ([conv.mem]) are considered. --end
note]</ins> If more than one function in the set remains ...

Wow. So now we have a further fix to the Note to [over.ics.rank]):

> Compared conversion sequences will have different source types only in
the context of <del>comparing the second standard conversion sequence
of</del> an initialization by user-defined conversion<ins>, specifically
when comparing the standard conversion sequence from the return type of a
viable function to the destination type</ins> (see [over.match.best])
<ins>or of taking the address of an overload set consisting of member
functions ([over.over])</ins>; in all other contexts, the source types will
be the same and the target types will be different.

And [over.ics.rank]/3.3 still has the dubious wording about aggregate
initialization.