Re: [boost] [type traits extension] test for const volatile& as return type

Subject: Re: [boost] [type traits extension] test for const volatile& as return type
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-07-08 00:09:28

On Thu, Jul 7, 2011 at 8:00 PM, Adam Merz <adammerz_at_[hidden]> wrote:
[...]

> My earlier post focused on whether calling `void g(int const volatile&)`
> with an
> int rvalue would be legal (it isn't), but that was partially misplaced --
> the
> relevant part of the standard is overload resolution.
>
> Starting from the top, quoting the C++03 standard, §13.3.3.1/3:
>
> > A well-formed implicit conversion sequence is one of the following forms:
> >   - a standard conversion sequence,
> >   - a user-defined conversion sequence, or
> >   - an ellipsis conversion sequence.
>
> §13.3.3.2/2:
>
> > When comparing the basic forms of implicit conversion sequences
> >   - a standard conversion sequence is a better conversion sequence than a
>      user-defined conversion sequence or an ellipsis conversion sequence,
> and
> >   - a user-defined conversion sequence is a better conversion sequence
> than an
>      ellipsis conversion sequence.
>
> §13.3.3.1.4 repeats multiple times that for the case where the parameter
> type is
> a reference, that a standard conversion is taking place; however I won't
> quote
> all that here.
>
> So with the overloads:
>
>    void g(int const volatile&);
>    void g(...);
>
> When calling g with an int rvalue, the compiler must select the
> `void g(int const volatile&)` overload because "a standard conversion
> sequence
> is a better conversion sequence than a user-defined conversion sequence or
> an
> ellipsis conversion sequence". Only then does the compiler decide that
> calling
> `void g(int const volatile&)` with an int rvalue is illegal. And this is
> not
> without precendence -- quoting §13.3.3.1.4/4:
>
> > Other restrictions on binding a reference to a particular argument do not
> > affect the formation of a standard conversion sequence, however.
> [Example: a
> > function with a "reference to int" parameter can be a viablecandidate
> even if
> > the corresponding argument is an int bit-field. The formation of implicit
> > conversion sequences treats the int bit-field as an int lvalue and finds
> an
> > exact match with the parameter. If the function is selected by overload
> > resolution, the call will nonetheless be ill-formed because of the
> prohibition
> > on binding a non-const reference to a bit-field.]
>
> Summary: Intel *is correct* according to the standarde, but GCC and MSVC
> take
> the sane/practical route.
>

What is a "standard conversion sequence"?

[ I don't have a copy of the standard; if it's freely available on the
internet somewhere, freely point me in the right direction :) ]

- Jeff