Daniel Walker wrote:
I would be perfectly happy using your <boost/lambda/result_of.hpp> for the nullary case alone, if we moved it to <boost/lambda/detail/result_of.hpp> and had the boost/lambda/* headers include it so that lambda/result_of interoperability was transparent to the user. That combined with the lambda patch would probably suffice.
I don't recommand the way to include implicitly. It would actually break codes written by the author of http://tinyurl.com/2xw4s2 , which is not mine. IMO, it should be separated, following Boost.Typeof way.
If user workarounds of sig-compatible functor users cannot be removed, that patch loses the original intention?
I'm not sure if I fully understand your question, but the patch doesn't lose the original intent entirely. Users can still use nary sig-compatible functors, which they couldn't use before. (However, as I stated above, it would be convenient but I'm not sure that it's necessary for result_of to support the current sig convention.) Lambda users are in the same boat as people writing result-compatible functors when it comes to nullary calls. They need to write a specialization of result_of for when their functor is called with no arguments. result_of doesn't attempt to automatically deduce the type, although it could with has_template_xxx.
After all, this seems to depend on the functionality and portability of has_template_xxx. I hope it will work under VC++. Regards, -- Shunsuke Sogame