A question was recently raised (elsewhere) about code like:

int foo()
{
   return 5;
}

const int bar()
{
   return 5;
}

void pass_int(int&& i)
{
   std::cout << "rvalue\n";
}

void pass_int(const int&& i)
{
   std::cout << "const rvalue\n";
}

Neither foo() nor bar() returns a reference, so according to =A7
[basic.lval]/5, they both return rvalues. According to =A7
[basic.lval]/10, "...non-class rvalues always have cv-unqualified
types." As such, it appears that both of the following should print
"rvalue":

   pass_int(foo());
   pass_int(bar());

At least some current compilers appear to distinguish the const
rvalue and invoke the const rvalue overload of pass_int() for it
(i.e., print "const rvalue"  for 'pass_int(bar());'). This behavior
seems desirable (at least to me). Nonetheless, the current wording of
the standard _seems_ to prohibit the behavior.

The statement about non-class rvalues always having cv-unqualified
types is retained (word for word) from the 2003 (and presumably 1998)
standards. At least to me, it appears that with the introduction of
rvalue references, the statement is no longer accurate and should be
stricken.

Proposed Resolution:

9       Rvalues shall always have (possibly cv-qualified) complete types
    or the void type; in addition to these types, lvalues can also
    have incomplete types.

This issue appears related (but not identical) to that raised in CWG
issue # 690. The resolution proposed here would probably interact
with the situated noted in the note that was added to issue 690 in
September 2009.

--
   Later,
   Jerry.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]