Re: [boost] [result_of] Usage guidelines

Subject: Re: [boost] [result_of] Usage guidelines
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-09-12 10:31:34

On Sat, Sep 8, 2012 at 11:34 AM, Andrey Semashev
<andrey.semashev_at_[hidden]>wrote:

> Ok, here is my second take on this. I've attached a patch with my changes.
>
> 1. I moved the guidelines to a separate section in order not to clutter the
> formal result_of description.
> 2. I seperately outlined the C++11 and C++03 recommendations.
> 3. I left the result_of examples. I think they illustrate the result_of
> usage
> quite well, but I'll be happy if someone comes up with something better.
> 4. I rephrased some of the wording about result<> usage, in response to
> Jeffrey's reply.
>
> Comments are welcome.
>

Regarding the signature one instantiates result_of with, the present
Boost.ResultOf documentation states that result_of< F ( T ) >::type is the
result of f(t) where f is an *lvalue* of type F and t is an *lvalue* of
type T. I've personally always found this needlessly limiting (precludes
deducing strictly correct result types for rvalue arguments), and it
appears to contradict what is expressed in this patch. I understand this
patch as strictly an addition to the present documentation, so I wonder if
it is appropriate to alter the existing Boost.ResultOf documentation text
to reflect these "new" usage guidelines (specifically, distinguishing
between lvalue and rvalue parameters).

"No additional scaffolding is needed from function objects, the compiler
will ..."
comma should be a semicolon

Regarding the example functor struct and the result specialization therein,
I like calling the first template parameter "This", to denote that it
should be approximately the same type as the enclosing class:

template< class > struct result;
template< class This, class T > struct result< This ( T ) > { typedef ...
type; };

Just a suggestion.

Regarding the use of "remove_cv< remove_reference<T>::type >::type", I
think this is pretty much what std::decay [1] was designed for (I hadn't
realized this existed until recently). boost::decay [2] is almost but not
quite functionally identical; perhaps it can be modified to add an
additional remove_cv (or does it do that already, and the boost::decay docs
just need to be tweaked)? Then Andrey's example would look a little cleaner.

- Jeff

[1] http://en.cppreference.com/w/cpp/types/decay
[2]
http://www.boost.org/doc/libs/1_51_0/libs/type_traits/doc/html/boost_typetraits/reference/decay.html