On 4/8/2010 4:25 PM, Daniel Walker wrote:
On Thu, Apr 8, 2010 at 6:51 PM, Eric Niebler <eric@boostpro.com> wrote:
On 4/8/2010 3:07 PM, Daniel James wrote:
This reverts the fixes for:
Support for boost.lambda.
This bug is invalid to begin with. Lambda should be changed to support the TR1 result_of protocol (which is standard), not the other way around.
No, the result_of in this patch can detect the type of any callable object, including those from boost.lambda, in contexts where the type of the call expression is complete. Now, lambda users who would like to query the type of lambda function objects should use their compiler's std::result_of, if it implements any draft of the standard from the past 2 years, or simply roll their own.
Hi Daniel, IIUC the fix here for Boost.Lambda was to implement the c++0x result_of on supporting compilers. That's fine -- as long as you accept that a decltype-based result_of is a safe substitute for the TR1 result_of, which I don't. My point above was that this bug should have been closed "Invalid" because it's not a result_of problem. The problem is that Lambda doesn't support the TR1 result_of protocol. This isn't news. The standard response is to use Phoenix. I don't particularly like that answer because ... (a) Phoenix isn't a top-level boost library and is likely to change once we get Phoenix ported to Proto, and (b) Lambda has a big installed user-base who won't benefit from improvements to Phoenix. But all this is a side issue. The real issue is to back out the decltype change (and ONLY the decltype change) to result_of on trunk, and merge the change to release as soon as we get the green light from the regression tests. Let me know if you need a patch for this. -- Eric Niebler BoostPro Computing http://www.boostpro.com