[boost] [result_of, phoenix] Inconsistency between result_of and tr1_result_of

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.
(* Boost.Lambda
  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`.
For example,
  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?

(Additional question:
Should we avoid the specialization of result_of when we use decltype-based
result_of?)

Regards,
Michel