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: Mostafa (mostafa_working_away_at_[hidden])
Date: 2013-10-01 12:55:39

On Tue, 01 Oct 2013 00:30:02 -0700, Jonathan Wakely  
<jwakely.boost_at_[hidden]> wrote:

> On 1 October 2013 05:45, Mostafa wrote:
>> On Mon, 30 Sep 2013 19:54:56 -0700, Gavin Lambert wrote:
>>
>>>
>>> A simple add_reference is obviously the wrong thing to be doing then.
>
> Indeed.
>
>>> In general, you can take any parameter type T and wrap it as a "const  
>>> T&"
>>> (or if you prefer, "T const&") and it will do the right thing, unless  
>>> T was
>>> already a reference.  But note that you must use a const reference -- a
>>> non-const reference won't work.
>>
>>
>> Not in my particular use case. The code I was working is generated by a  
>> mix
>> of PPMP and TMP techniques. The argument x is eventually forwarded to  
>> some
>> user block of code, where the user expects it to be of the same type as  
>> the
>> one he/she specified in the signature of SomeUserClass::foo. So had the  
>> user
>> specified this instead:
>>
>> struct SomeUserClass
>> {
>>   static void foo(int x)
>>   {
>>     SomeCodeGenClass::foo(x);
>>   }
>> };
>>
>> Then it is expected that x would be mutable in that forwarded-to block  
>> of
>> code.
>
> Well then you're doing it wrong. You should base the forwarded
> parameter type on decltype(x) not the parameter type in the function
> signature.  The function signature doesn't include the top-level
> const, that's how C++ works.

Yup, and that's what I basically concluded way back in my response to  
Sergey's post. (Though decltype was not considered since I'm targeting  
C++03.)