Subject: [boost] [result_of, phoenix] Inconsistency between result_of and tr1_result_of
From: Michel Morin (mimomorin_at_[hidden])
Date: 2012-05-16 07:15:28
To support nullary-callable polymorphic function objects
in C++03 `result_of`, we have to specialize `result_of` for the
zero-argument case. (If we don't provide specializations,
the type determined by C++03 `result_of` for zero-argument
function calls is defaulted to void. See the rationale in N1454.)
Library authors have implemented the specialization for `result_of`
to support the zero-argument case. But, in most cases, they have
not specialized `tr1_result_of`. I checked a few Boost libraries:
* Boost.Phoenix and Boost.Functional/Forward
Only `result_of` is specialized; `tr1_result_of` is not specialized.
Neither `result_of` nor `tr1_result_of` is specialized. So `result_of` and
`tr1_result_of` for nullary function calls always evaluate to `void`.)
This results in inconsistency between `result_of` and `tr1_result_of`.
boost::result_of< decltype(boost::phoenix::val(3))() >::type
evaluates to `int const&`. But
boost::tr1_result_of< decltype(boost::phoenix::val(3))() >::type
evaluates to `void`.
Shouldn't we provide specializations for both `result_of` and `tr1_result_of`
to make result_of and tr1_result_of equivalent?
Should we avoid the specialization of result_of when we use decltype-based
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk