c++ - Constraint does not disambiguate function in base class from function in derived class, in clang 18gcc trunk - Stack Overf

admin管理员组

文章数量:1344334

The following code compiles (in C++20 mode) on gcc version <= 14, and on clang version <=17, not on clang 18 and gcc trunk ():

#include <iostream>
#include <concepts>

struct A {
    void f() { std::cout << "A::f\n"; }
};

template <class T>
struct B : public A {
    // Intention: use B::f if T is int. Use A::f otherwise.
    using A::f;
    void f() requires std::same_as<T, int> {
        std::cout << "B::f";
    }
};

int main() {
    B<int>().f(); // <-- clang 18 and gcc trunk: "error: call to 'f' is ambiguous"
}

Clang's error is the following, and gcc's is very similar:

<source>:18:14: error: call to member function 'f' is ambiguous
   18 |     B<int>().f(); // <-- clang 18: "error: call to member function 'f' is ambiguous"
      |     ~~~~~~~~~^
<source>:5:10: note: candidate function
    5 |     void f() { std::cout << "A::f\n"; }
      |          ^
<source>:12:10: note: candidate function
   12 |     void f() requires std::same_as<T, int> {
      |          ^

Both I, and gcc version <= 14, and clang version <= 17, think that the call seems non-ambiguous because B::f is more constrained than A::f, so B::f can be preferred. But if both compilers generate the error in more recent versions, I do realize that they are probably right and there is something I don't understand...

1. Which is the correct behavior, according to the standard? Why can't it resolve the call by choosing the more constrained f?

2. I see that I can make this work by replacing using A::f; by void f() { A::f(); } in B, and this works also in my real world code. But this pattern could potentially be harder to apply if the base class contains many overloads of the function, and/or the function prototypes are complex. Is there a workaround that does not require duplicating all prototypes from the base class into the derived class?

The following code compiles (in C++20 mode) on gcc version <= 14, and on clang version <=17, not on clang 18 and gcc trunk (https://godbolt./z/hvre4x8Pc):

#include <iostream>
#include <concepts>

struct A {
    void f() { std::cout << "A::f\n"; }
};

template <class T>
struct B : public A {
    // Intention: use B::f if T is int. Use A::f otherwise.
    using A::f;
    void f() requires std::same_as<T, int> {
        std::cout << "B::f";
    }
};

int main() {
    B<int>().f(); // <-- clang 18 and gcc trunk: "error: call to 'f' is ambiguous"
}

Clang's error is the following, and gcc's is very similar:

<source>:18:14: error: call to member function 'f' is ambiguous
   18 |     B<int>().f(); // <-- clang 18: "error: call to member function 'f' is ambiguous"
      |     ~~~~~~~~~^
<source>:5:10: note: candidate function
    5 |     void f() { std::cout << "A::f\n"; }
      |          ^
<source>:12:10: note: candidate function
   12 |     void f() requires std::same_as<T, int> {
      |          ^

Both I, and gcc version <= 14, and clang version <= 17, think that the call seems non-ambiguous because B::f is more constrained than A::f, so B::f can be preferred. But if both compilers generate the error in more recent versions, I do realize that they are probably right and there is something I don't understand...

1. Which is the correct behavior, according to the standard? Why can't it resolve the call by choosing the more constrained f?

2. I see that I can make this work by replacing using A::f; by void f() { A::f(); } in B, and this works also in my real world code. But this pattern could potentially be harder to apply if the base class contains many overloads of the function, and/or the function prototypes are complex. Is there a workaround that does not require duplicating all prototypes from the base class into the derived class?

• c++
• language-lawyer
• c++20
• c++-concepts

Share Improve this question Follow edited yesterday 康桓瑋 43.3k55 gold badges6363 silver badges126126 bronze badges asked yesterday Sven SandbergSven Sandberg 18366 bronze badges 3

• There are a similar "issue" with SFINAE case (so template with special wording), not sure how the wording evolve with constraints. – Jarod42 Commented yesterday
• 1 What language version are you asking the compilers to use? It's not clear from "gcc version <= 14, and clang version <= 17" whether those are compiler versions or language versions. – Jesper Juhl Commented yesterday
• Good point about language vs compiler version. I meant compiler versions, and in both cases compiling in C++20 mode. Clarified the question. – Sven Sandberg Commented yesterday

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 2

This behavior change is related to CWG2789, which made this example ambiguous.

Per [over.match.funcs.general]/4, the types of the implicit object parameters of both candidates are considered to be the same in this case, so neither function is better than the other based on the ranking of implicit conversion sequences.

The only thing distinguishing them, then, is the requires-clause. In C++20 (and C++23) as published, the relevant tiebreaker ([over.match.best.general]/2.6) reads:

... a viable function F₁ is defined to be a better function than another viable function F₂ if [...]

• F₁ and F₂ are non-template functions with the same parameter-type-lists, and F₁ is more constrained than F₂ according to the partial ordering of constraints described in [temp.constr.order]

(The referenced subclause considers a declaration with associated constraints to be more constrained than one without, as you'd expect.)

CWG2789 changed this to:

• F₁ and F₂ are non-template functions and
  • they have the same non-object-parameter-type-lists, and
  • if they are member functions, both are direct members of the same class, and
  • if both are non-static member functions, they have the same types for their object parameters, and
  • F₁ is more constrained than F₂ according to the partial ordering of constraints described in [temp.constr.order]

Since the two f are not direct members of the same class, this bullet no longer applies, and the call is ambiguous.

Yes, this should work: [over.match.funcs.general]/4 specifies that implicit-object member functions are not distinguished by their originating class during overload resolution (so the B& that is *this isn’t a better match for B’s member function than for A’s). Perhaps the compilers are confused by their support for explicit-object member functions added in recent versions.

本文标签：