Re: [boost] [result_of] Usage guidelines

Subject: Re: [boost] [result_of] Usage guidelines
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-09-12 11:16:37

On Wednesday 12 September 2012 07:31:34 Jeffrey Lee Hellrung, Jr. wrote:
> 
> 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).

Good catch, I missed that limitation in the formal result_of description. 
Indeed, with the current wording the meaning of result_of<f(int)>::type is 
unclear.

std::result_of<F(T)> is defined in terms of std::declval<T>() which 
effectively means that when T is not a lvalue reference, the argument is 
assumed to be rvalue. This is outlined in the guidelines and I think, the 
formal description should be updated accordingly, unless there are some 
background reasons not to.

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

Will do.

> 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.

Ok, I just followed the pattern of the previous examples.

> 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.

boost::decay doesn't do remove_cv, so it can't be used as a replacement. It 
should probably be updated to reflect std::decay, but until then 
remove_cv+remove_reference will have to stay, I guess.