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

Subject: Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-09-26 06:02:12

On Thu, Sep 26, 2013 at 1:28 PM, Rob Stewart <robertstewart_at_[hidden]>wrote:

> On Sep 25, 2013, at 5:09 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
> 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.