c++ copy initialization & direct initialization, the weird case

Question

Before continue reading this, please read Is there a difference in C++ between copy initialization and direct initialization? first, make sure you understand what it is talking about.

I'll summarize the rule here first (read standard n3225 8.5/16, 13.3.1.3, 13.3.1.4, and 13.3.1.5),

1) For direct initialization, all constructors will be considered as the overloading set, the overloading resolution will select the best one according to the overloading resolution rules.

2) For copy initialization and the source type is the same as destination type or derived from destination type, the rule is as same as above except that only converting constructors (constructors without explicit) will be considered as the overloading set. This actually means explicit copy/move constructors will not be considered into the overloading set.

3) For copy initialization cases not included in (2) above (source type is different from destination type and not derived from destination type), we first consider user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof. If the conversion succeeds, the result is used to direct initialize the destination object.

3.1) During this user-defined conversion sequence, both converting ctors (non-explicit ctors) and non-explicit conversion functions will be considered, according to rules in 8.5/16 and 13.3.1.4.

3.2) The result prvalue will direct initialize the destination object, as rules listed in (1), see 8.5/16.

Okay, enough for rules, let's look at some weird code, which I really have no idea on where my reasoning is wrong, or just all compilers are wrong. Please help me, thanks.

struct A
{
    A (int) { }
    A() { }
    explicit A(const A&) { }
};
struct B
{
    operator A() { return 2; }
    //1) visual c++ and clang passes this
    //gcc 4.4.3 denies this, says no viable constructor available
};
int main()
{
    B b;
    A a = b;
    //2) oops, all compilers deny this
}

In my understanding, for (1),

operator A() { return 2; }

Because C++ has a rule that function return is taken as copy-initialization, according to the rule above, 2 will be firstly implicitly converted to A, which should be OK because A has a constructor A(int). Then the converted temporary prvalue will be used to direct-initialize the returned object, which should be OK too because direct-initialization can make use of the explicit copy constructor. So GCC is wrong.

For (2),

A a = b;

In my understanding, firstly b is implicitly converted to A, by operator A(), and then the converted value shall be used to direct-initialize a, which can of course call the explicit copy constructor? Thus this should pass compilation and all compilers are wrong?

Note that for (2), both visual c++ and clang has an error similar to, "Error, cannot convert from B to A", but if I remove the explicit keyword in the copy constructor of A, the error is gone..

Thanks for reading.

---

edit 1

Because somebody still didn't get what I meant, I quote the following standard from 8.5/16,

Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in 13.3.1.4, and the best one is chosen through overload resolution (13.3). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualified version of the destination type. The temporary is a prvalue. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see 12.2, 12.8.

Note that it did mention direct initialize after the user-defined conversion. Which means, in my understanding, the following code shall obey the rules as what I commented, which is confirmed by both clang, coomeau online, visual c++, but GCC 4.4.3 fails both (1) and (2). Although this is a weird rule, but it follows the reasoning from the standard.

struct A
{
    A (int) { }
    A() { }
    explicit A(const A&) { }
};

int main()
{
    A a = 2;    //1)OK, first convert, then direct-initialize
    A a = (A)2; //2)oops, constructor explicit, not viable here!
}

Answer 1

You declared your copy constructor explicit (BTW, why?), which means that it can no longer be used for implicit copying of class objects. In order to use this constructor for copying you are now forced to use direct-initialization syntax. See 12.3.1/2

2 An explicit constructor constructs objects just like non-explicit constructors, but does so only where the direct-initialization syntax (8.5) or where casts (5.2.9, 5.4) are explicitly used.

The issue can be illustrated by the following much shorter example

struct A {
  A() {}
  explicit A(const A&) {}
};

int main() {
  A a;
  A b = a; // ERROR: copy-initialization
  A c(a); // OK: direct-initialization
}

This is what blocks all of your conversions from working, since all of them rely on copy-initialization, which in turns relies on implicit copying. And you disabled implicit copying.

Additionally, see the Defect Report #152 which covers this specific issue. Although I'm not sure what the consequences of the "proposed resolution" are supposed to be...

Answer 2

As you mentioned, gcc doesn't compile the following code.

struct A {
  A( int ) {}
  explicit A( A const& ) {}
};

int main() {
  A a = 2;
}

I think this isn't standard conformant according to current standard 8.5 p15.
However, as for your first case,

struct A {
  A( int ) {}
  explicit A( A const& ) {}
};

struct B {
  operator A() { return 2; }
};

int main() {
  B b;
  A a = b;
}

I'm not convinced that allowing this is conformant.
As you may know, return will invoke copying twice conceptually.
return 2; constructs an A implicitly from an int 2, and it is used to direct-initialize a temporal return-value(R).
However, should direct-initialization be applied to the second copying from R to a?
I couldn't find the wording in current standard which explicitly states that direct-initialization should be applied twice.
Since it is certain that this sequence spoils explicit specification in a sense, I'm not surprised even if compiler developers thought allowing this is a defect.

Let me make an unnecessary addition.
A compiler's non-conformant behaviour doesn't mean that the compiler has a defect directly.
The standard already has defects as defect reports show.
For example, the C standard doesn't allow the conversion from a pointer to an array of type T, to a pointer to an array of const T.
This is allowed in C++, and I think it should be allowed semantically in C similarly.
Gcc issues a warning about this conversion. Comeau issues an error, and doesn't compile.