On 9/5/12 11:12 PM, Eric Niebler wrote:
On 9/4/2012 10:32 PM, Jeffrey Lee Hellrung, Jr. wrote:
In any case, I still think your use of result_of in the given example was brittle and, ultimately, a misuse, whether we're speaking of the TR1-based or the decltype-based result_of.
Yes.
AFAIK, result_of has never had any guarantees as far as instantiating it with invalid call signatures.
Correct. And in C++11, std::result_of doesn't make that guarantee either. From Table 53 in 20.7.6.6 describing the requirements of std::result_of:
"Fn shall be a function object type (20.8), reference to function, or reference to function object type. The expression decltype(declval<Fn>()(declval<ArgTypes>()...)) shall be well formed."
Joel, I know you're annoyed by this change. But in truth, you were relying on an implementation detail of result_of. The list of gotchas in the release notes will include this case.
I am not in anyway annoyed. I am just pointing out the problems of result_of in real code. You keep in saying "you". In fact, it's not me. That part of the code is Tobias'; The phoenix-3 code using result_of is Thomas', keep in mind that Phoenix-2 uses its own result protocol. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com