Why const for implicit conversion?

Question

After extensive reading of ISO/IEC 14882, Programming language – C++ I'm still unsure why const is needed for implicit conversion to a user-defined type with a single argument constructor like the following

#include <iostream>

class X {
public:
   X( int value ) {
      printf("constructor initialized with %i",value);
   }
}

void implicit_conversion_func( const X& value ) {
   //produces "constructor initialized with 99"
}

int main (int argc, char * const argv[]) {
   implicit_conversion_func(99);
}

Starting with section 4 line 3

An expression e can be implicitly converted to a type T if and only if the declaration T t=e; is well-formed, for some invented temporary variable t (8.5). Certain language constructs require that an expression be converted to a Boolean value. An expression e appearing in such a context is said to be contextually converted to bool and is well-formed if and only if the declaration bool t(e); is well-formed, for some invented temporary variable t (8.5). The effect of either implicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is an lvalue reference type (8.3.2), and an rvalue otherwise. The expression e is used as an lvalue if and only if the initialization uses it as an lvalue.

Following that I found the section on initializers related to user-defined types in 8.5 line 6

If a program calls for the default initialization of an object of a const-qualified type T, T shall be a class type with a user-provided default constructor.

Finally I ended up at 12.3 line 2 about user-defined conversions which states

User-defined conversions are applied only where they are unambiguous (10.2, 12.3.2).

Needless to say, 10.2 and 12.3.2 didn't answer my question.

1. Can someone shed some light on what effect const has on implicit conversions?
2. Does the use of const make the conversion "unambiguous" per 12.3 line 2?
3. Does const somehow affect lvalue vs. rvalue talked about in section 4?

Answer 1

It doesn't really have much to do with the conversion being implicit. Moreover, it doesn't really have much to do with conversions. It is really about rvalues vs. lvalues.

When you convert 99 to type X, the result is an rvalue. In C++ results of conversions are always rvalues (unless you convert to reference type). It is illegal in C++ to attach non-const references to rvalues.

For example, this code will not compile

X& r = X(99); // ERROR

because it attempts to attach a non-const reference to an rvalue. On the other hand, this code is fine

const X& cr = X(99); // OK

because it is perfectly OK to attach a const reference to an rvalue.

The same thing happens in your code as well. The fact that it involves an implicit conversion is kinda beside the point. You can replace implicit conversion with an explicit one

implicit_conversion_func(X(99));

and end up with the same situation: with const it compiles, without const it doesn't.

Again, the only role the conversion (explicit or implicit) plays here is that it helps us to produce an rvalue. In general, you can produce an rvalue in some other way and run into the same issue

int &ir = 3 + 2; // ERROR
const int &cir = 3 + 2; // OK

Answer 2

Per section 5.2.2 paragraph 5, when an argument to a function is of const reference type, a temporary variable is automatically introduced if needed. In your example, the rvalue 99 has to be put into a temporary variable so that that variable can be passed by (const) reference to the constructor of X.

Were the reference argument not const, the compiler would not be able to silently introduce a temporary, which would consequently prevent the automatic constructor call.

The semantics of creating a non-const temporary there would in any case be rather confusing -- what happens if the constructor clobbers the temporary, and what bizarre side effects could that end up having? (Think std::auto_ptr<T> -- the pointer on the right hand side would silently be robbed of its referent!)

Answer 3

AndreyT is totally correct.

However it's worth pointing out in his response what an rvalue and an lvalue are.

An "rvalue" is a value that can go on the right-hand-size of an assignment -- hence the "r". An "lvalue" can go on the left-hand-size, hence the "l".

More exactly, an lvalue has an address in memory, while an rvalue may not.

Technically all lvalues are also rvalues, since anything that can go on the left-hand side can also go on the right -- otherwise you couldn't do things like this:

int x = y = 3;

Therefore, it's more exact to refer to lvalues and non-lvalues, since rvalue isn't specific.

http://en.wikipedia.org/wiki/Value_(computer_science)