Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?

26 Sep 2013

      On Thu, Sep 26, 2013 at 1:28 PM, Rob Stewart wrote:
...
On Sep 25, 2013, at 5:09 AM, Andrey Semashev 
wrote:
...
I have to say that while these rules are logical and understandable when
explained, types of function arguments are a constant source of
confusion.
There are many things about C++ that are contrary to someone's intuition.
That parameter declaration is no different than the following variable:
int const i;
When used with either of the forms of f(), above, does i work any
differently than j, below?
int j;
They work alike with either f(), because the int is copied. The difference
is whether you can change the int after initialization. The parameters are
no different.
Sure, they work the same, from the caller's perspective. But is that a
reason to cheat with the type system?

void foo(int);
void bar(const int);

typeid(&foo) == typeid(&bar); // why?

My point was that despite the same behavior on the caller's side, the
functions have different signatures, and I don't see why there was a
_necessity_ to force the compiler to drop cv-qualifiers from the function
argument types. In other words, it makes the language more complicated for
no apparent reason.
...
...
But C++11 brought us
rvalue references, and the following:
foo(int&& n)
 {
   // n is _not_ rvalue reference here
 }
I understand the rationale for this, and it seems the right thing. But
once in a while, when yet another fellow developer asks me why is that so,
I wonder if it would be better if the standard was more straight-forward in
this part.
The issue comes down to one of consequences. If n were still an rvalue,
within foo(), even when referenced by name, what problems will that cause?
AFAIR, the motivating example was something like this:

  void bar(int&& n); // moves from n

  void foo(int&& n)
  {
    bar(n);
    bar(n); // moves from a moved-from object
    ++n; // uses a moved-from object
  }

This can be a real gotcha, I admit. But just as well as this:

  class my_class
  {
    vector<int> vec;

  public:
    my_class(vector<int>&& v) : vec(v) // copies the vector, instead of
moving
    {
    }
  };

This latter mistake is usually less critical, but for that reason it is
also more often made and left unnoticed.