Subject: Re: [boost] [Fit] formal review ends 20th March.
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-03-22 12:41:22
On Tuesday, March 22, 2016 at 3:52:23 AM UTC-5, Bjorn Reese wrote:
> On 03/21/2016 07:04 PM, Paul Fultz II wrote:
> > However, with lambdas it is the opposite. Lambdas default to const and
> > an
> > explicit mutable keyword is needed for a mutable function object.
> The const-by-default lambdas are the black swans of C++.
Other than working around bugs in MSVC, I have never used a mutable lambda
any of the codebases I have worked on. I find it quite surprising that const
lambdas are considered a "black swan".
> The fit documentation should at least provide a design rationale for
> its const-by-default decision which is addressed at those who are
> unfamiliar with the virtues of immutability.
> Another concern with fit::mutable_ is its name. As you have already gone
> down the type-traits naming path with fit::decay, it may be an idea to
> rename fit::mutable_ to fit::remove_const.
No, fit::decay works something like this(ignoring unwrapping references):
std::decay_t<T> decay(T&& x)
It simply transforms the type according to the rules of the type trait
std::decay. So, fit::remove_const would imply the same:
remove_const_t<T> decay(T&& x)
However, fit::mutable_ does not work that way at all. It is an adaptor, so
only accepts a function object, and returns a function object. Even more
does not remove const at all, not even from the function object call
Rather, fit::mutable_ creates a new function object with const added to the
call operator. However, calling it fit::add_const would imply that it would
prevent mutablilty which is not the case.
So I think fit::mutable_ is a much better name, as it actually describes
is happening to the object using the same terminology that is used for
lambdas. Plus, it the describes the C++ mechanism that is used to implement
fit::mutable_ as well(that is the adaptor uses the mutable keyword).
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk