If
T1 or
T2 is a class type and
T1 is not reference-related to
T2,
user-defined conversions are considered
using the rules for copy-initialization of an object of type
“
cv1 T1” by
user-defined conversion
(
[dcl.init],
[over.match.copy],
[over.match.conv]);
the program is ill-formed if the corresponding non-reference
copy-initialization would be ill-formed. The result of the call to the
conversion function, as described for the non-reference
copy-initialization, is then used to direct-initialize the reference.
For this direct-initialization, user-defined conversions are not
considered.
If I read this literally, then initializing
const std::string& from a string literal should create a
cv-unqualified temporary of type
std::string. This is because the "conversion function" called by the corresponding non-reference copy-initialization is a constructor, and according to
[dcl.init]/17.6.3, the constructor call is considered to yield a cv-unqualified prvalue which is then used to initialize the possibly cv-qualified object.
I think that this is probably not the intended interpretation, but it is impossible to tell for sure because the wording is not clear. I suspect that the real intent of p5.4.1 is that the temporary is materialized with type cv1 T1. The reason why I say this is that p5.3 contains such a provision explicitly. Furthermore, the C++11 wording that governs similar initializations also says that the temporary is created with type cv1 T1. It would be surprising to me if the intent of p5.4.1 is to create a cv-unqualified temporary.
I am thinking of filing a DR. Does anyone think this is not a defect? If so, why?