Re: [boost] [Fit] formal review ends 20th March.

Subject: Re: [boost] [Fit] formal review ends 20th March.
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-21 19:55:02

On 3/21/2016 6:07 PM, Paul Fultz II wrote:
>
>
> On Monday, March 21, 2016 at 4:53:58 PM UTC-5, Edward Diener wrote:
>>
>> On 3/21/2016 2:04 PM, Paul Fultz II wrote:
>>>
>>>
>>> On Sunday, March 20, 2016 at 9:07:53 PM UTC-5, Gavin Lambert wrote:
>> ... snipped
>>>> I think it's still true that mutable functions are useful
>>>> in more cases -- despite being vulnerable to surprise copies and
>>>> thread-safety issues.
>>>>
>>>> (Having said that, this may be because boost::bind is used in most
>> cases
>>>> where const function objects would otherwise be used, so that custom
>>>> function objects are typically only created where they need to be
>>>> mutable; the code does not yet make extensive use of lambdas.  But I
>>>> don't think my experience is unique.)
>>>>
>>>
>>> I would like to note, that the const requirement only applies to
>> function
>>> objects. You can pass member function pointers to member functions that
>> are
>>> mutable.
>>
>> You probably meant to say "You can pass member function pointers for
>> mutable member functions". I would also strongly suggest you use the
>> terms 'const' and 'non-const' when referring to member functions rather
>> than 'const' and 'mutable' in your documentation. The reason I believe
>> this is less confusing is because 'mutable' is a C++ keyword and as a
>> keyword means something entirely different from how you are using it in
>> your documentation.
>
>
> How is it different? The mutable keyword is used to signify the function as
> non-const. That is when I write:
>
> auto f = [] mutable {};
>
> It is the equivalent of writing a class with a "non-const" call operator
> like
> this:
>
> struct local_f{ void operator()() {} // No const here };
> auto f = local_f{};

If I have a class:

struct MyClass
{
void MyFunction( /* SomeParammeters etc. */ );
void AnotherFunction( /* SomeParammeters etc. */ ) const;
}

If I choose to discuss the 'constness' of member functions I don't refer 
to MyFunction as opposed to AnotherFunction as being 'mutable' but 
instead I say that MyFunction is 'non-const' and AnotherFunction is 
'const'. Even you are using 'non-const' as in 'It is the equivalent of 
writing a class with a "non-const" call operator'. I do not think that 
member functions are ever referred to as 'mutable' as opposed to 
'non-const' in common C++ parlance. The fact that lambda functions 
specify 'mutable' to refer to a 'non-const' lambda function as opposed 
to the default 'const' lambda function seems irrelevant to me here.