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?
> >
> >
>

-- 
*Brian Bi*