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-07 20:50:30

On Thu, Jul 7, 2011 at 4:27 PM, Adam Merz <adammerz_at_[hidden]> wrote:

> Frédéric Bron <frederic.bron <at> m4x.org> writes:
> > <snip>
> > g++ is just fine for what I want to do but intel issues an error if T
> > is "const volatile&" so that the program cannot compile and the g(...)
> > is not chosen. Does anybody understands if this is the right behaviour
> > according to the standard or if g++ is right chosing g(...)?
>
> By my reading, the Intel compiler is correct in refusing to compile.
> Quoting
> §8.5.3/5 from the C++03 standard:
>
> > A reference to type "cv1 T1" is initialized by an expression of type "cv2
> T2"
> > as follows:
> >   - If the initializer expression
> >     - [1] is an lvalue (but is not a bit-field), and "cv1 T1" is
> reference-
> >       compatible with "cv2 T2," or
> >     - [2] has a class type (i.e., T2 is a class type) and can be
> implicitly
> >       converted to an lvalue of type "cv3 T3," where "cv1 T1" is
> reference-
> >       compatible with "cv3 T3" (this conversion is selected by
> enumerating the
> >       applicable conversion functions and choosing the best one through
> >       overload resolution),
> >     then <snip...>
> >   - [3] Otherwise, the reference shall be to a non-volatile const type
> (i.e.,
> >     cv1 shall be const).
>
> If I interpret this correctly,
> - [1] is not applicable because you're passing an rvalue
> - [2] is not applicable because int is not a class type
> - [3] specifically disallows volatile
>
> Obviously the wording in the C++0x FDIS differs, but still ultimately
> disallows
> this particular scenario.
>
> That said, I'm inclined to say that GCC and MSVC are in the wrong here, not
> Intel.
>

By this logic,

void f(int&);
void f(...)
f(i++)

should also fail to compile, no?

I would think that the failure of an int rvalue to initialize either an int&
or an int const volatile & would simply drop that overload from
consideration.

- Jeff