David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
That's because your "move" constructor is not a move constructor from language point of view (i.e. it has no special status). As I understand it, the compiler's thought process goes somewhat like: need to create a temporary, but it can be elided, so we'll just access check the copy constructor. The compiler doesn't want to backtrack and try not to elide the temporary, which would've succeeded.
OK, so 8.5.3/5 says:
A temporary of type ``cv1 T2'' [sic] is created, and a constructor is called to copy the entire rvalue object into the temporary. The reference is bound to the temporary or to a sub-object within the temporary.*
[Footnote: Clearly, if the reference initialization being processed is one for the first argument of a copy constructor call, an implementation must eventually choose the first alternative (binding without copying) to avoid infinite recursion. --- end foonote]
The constructor that would be used to make the copy shall be callable whether or not the copy is actually done.
The problem here is, IIUC, that the implementors read that as saying that, because "a constructor is called to copy..." that the constructor used must be a copy constructor?
I don't understand why the converting constructor fails to be considered when the templated SFINAE'd constructor *will* be used to copy const lvalues. Templated constructors are never "copy ctors" either, IIUC.
(As I already mentioned) http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#291: <Q> Another detail worth of note is that in the *draft* version of the Standard as of 2 December 1996 the second bullet read: A temporary of type "cv1 T2" [sic] is created, and a *copy constructor* is called to copy the entire rvalue object into the temporary... J. Stephen Adamczyk replied that the reason for changing "a copy constructor" to "a constructor" was to allow for member template converting constructors. </Q> This relaxation makes any viable converting constructor legitimate for constructing this temporary and therefore the syntactic constraint is met which makes your (and Andrei's) suggestion perfectly functional in the boundaries of the current standard. Regards, Rani