Additional notes (August 2026)

Consider:

  struct A {
    operator int();
  };
  struct B {
    operator int();
  };
  struct C : A, B {
    operator short();
  } c;
  short s = c;  // ought to be OK and call operator short
  int n = c;    // ambiguous base class conversion during overload resolution with prior wording

Also consider:

  struct A {
  protected:
    operator int() &&;
  };
  struct B {
  protected:
    operator int();
  };
  struct C : A, B {} c;
  int n2 = c;

The current rule weirdly allows this, yet there is no other way to invoke C::operator int.

Consider:

  class B {
    protected:
      operator int&() { static int x; return x; }
  };

  struct D : B { using B::operator int&; };

  int x = D();   // OK

The function B::operator int& is a candidate, but the using-declaration in D is not considered when checking accessibility, because name lookup is not actually performed.

Suggested resolution:

Change in 12.2.2.1 [over.match.funcs.general] paragraph 7 as follows:

In each case where conversion functions of a class S are considered for initializing an object or reference of type T, the candidate functions include the result of a search for the conversion-function-id operator T in S. [Note 3: This search can find a specialization of a conversion function template (6.5 [basic.lookup]). —end note] Each such case also defines sets of permissible types for explicit and non-explicit conversion functions; for each (non-template) conversion function F that

• is a non-hidden member of S,
• yields a permissible type U, and,
• for the former set, is non-explicit,

is also a candidate function if looking up operator U in the scope of S succeeds and finds a declaration of F, that declaration is added to the candidate set. If initializing an object, for any permissible type cv U, any cv2 U, cv2 U&, or cv2 U&& is also a permissible type. If the set of permissible types for explicit conversion functions is empty, any candidates that are explicit are discarded.