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.