Indeed, you are right. I don't know how did I miss that the condition in 5.3.1 is met here.

On 01/04/2020 00:28, Brian Bi wrote:
> I think you got the reference wrong - the condition in p5.3.1 is the one
> that should be met with the std::string prvalue. But it seems your
> conclusion is correct - p5.3 requires the materialized temporary to have
> *cv1*. I guess that resolves the question.
>
> On Sun, Mar 29, 2020 at 1:43 PM <language.lawyer_at_[hidden]> wrote:
>
>> [dcl.init.ref]/5.4.1 says that the result of the call to the conversion
>> function is used to initialize the reference.
>> The result is a cv-unqualified prvalue, but when it is used to
>> direct-initialize the `const std::string&` reference, we get to
>> [dcl.init.ref]/5.4.2 where the prvalue obtains its const qualifier before
>> temporary materialization.
>>
>> No?
>>
>> On 28/03/2020 00:10, Brian Bi via Std-Discussion wrote:
>>> Inspired by: https://stackoverflow.com/q/60893342/481267 where const
>>> std::string& is being initialized from a string literal.
>>>
>>> This is controlled by [dcl.init.ref]/5.4.1
>>> <http://eel.is/c++draft/dcl.init.ref#5.4.1>:
>>>
>>> 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] <http://eel.is/c++draft/dcl.init>,
>> [over.match.copy]
>>> <http://eel.is/c++draft/over.match.copy>, [over.match.conv]
>>> <http://eel.is/c++draft/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 <http://eel.is/c++draft/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?
>>>
>>>
>>
>
>