Opened 10 years ago
Last modified 5 years ago
#6911 assigned Bugs
[Phoenix V3] Add tr1_result_of specialization
Reported by: | Michel Morin | Owned by: | Kohei Takahashi |
---|---|---|---|
Milestone: | Boost 1.67.0 | Component: | phoenix |
Version: | Boost Development Trunk | Severity: | Problem |
Keywords: | Cc: |
Description
To make result_of
and tr1_result_of
equivalent, we have to add specialization of tr1_result_of
.
(Boost.Phoenix V3 already has specialization of result_of
.)
Also, it would be nice to avoid specialization of result_of
, when we use decltype-based result_of
.
(As for tr1_result_of
, it should be specialized even when decltype-based result_of
is used.)
So, instead of
template <...> struct result_of<F()> { typedef XXXX type; };
we should write
#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE) template <...> struct result_of<F()> { typedef XXXX type; }; #endif template <...> struct tr1_result_of<F()> { typedef XXXX type; };
A quick grep said the following files specialize result_of
.
- phoenix/core/actor.hpp
- phoenix/function/function.hpp
Change History (4)
comment:1 by , 5 years ago
Owner: | changed from | to
---|
comment:2 by , 5 years ago
Ah, result_of
derives from tr1_result_of
even for nullary calls.
So the specialization of result_of
is verbose.
Thanks for the correction!
comment:3 by , 5 years ago
Status: | new → assigned |
---|
Here is candidate patch for fixing this issue, but test is needed.
https://github.com/boostorg/phoenix/commit/0d1af868ae86ff9ff1e791255af286a25ecf370e
comment:4 by , 5 years ago
Milestone: | To Be Determined → Boost 1.67.0 |
---|
IMO, those specialization aim for returning non void type on TR1 result_of, so only
tr1_result_of
specialization is needed.