On 4/12/2010 8:05 AM, Daniel Walker wrote:
On Sun, Apr 11, 2010 at 5:47 PM, Eric Niebler <eric@boostpro.com> wrote:
I opened a ticket for this (milestone 1.44) and attached a patch: https://svn.boost.org/trac/boost/ticket/4084.
I like the idea and the patch looks good. How do I go about getting it on trunk? I don't believe I have check-in rights.
If you're a library maintainer, you need svn commit permission. I'm not sure who the gate-keeper of svn is these days. Please send a separate message to the list asking for permission. If you want, I can apply this patch. Or John can do it because it touches his code, too.
The regression test failures may be more evidence that the change to result_of was a bad idea (as well-intentioned as it may have seemed). This patch may not be the last word on the issue. I'm still uncomfortable with the change to boost::result_of, which is likely to break users' code. Perhaps we could place the new decltype implementation on a compile-time switch (BOOST_RESULT_OF_USE_DECLTYPE?) so that users can opt in. That wouldn't eliminate the need for boost::tr1_result_of or something like it, though.
Ultimately, boost::result_of should behave as intended whenever possible; i.e. it should evaluate to the type of a call expression. <snip>
This is a strident position ... and wrong. Intention has nothing to do with it. Boost::result_of should behave as *specified*. The current documentation for boost::result_of specify it to use the TR1 result_of protocol. Users have come to rely on it. The TR1 behavior is not a bug. It's a standard. And if you want to talk about *standard* specifications, there are 2 to choose from (or will be soon): TR1 and C++0x. One can be implemented with complete fidelity on every major supported compiler. The other can only be supported on the newest compilers and is still in flux due to a bug in the specification of decltype. I think going with the second is premature, even if you forget about the LOCs you'll break. Intentions and specifications aside, you are now the maintainer of one of the most heavily used and essential pieces of Boost infrastructure. Not breaking code should be a factor in your decisions. If you want to change behavior, you need a migration path. Putting the new (experimental and buggy) behavior on a switch so users can opt in is a reasonable first step. It should be accompanied with documentation, release notes, and an effort to educate boost developers and users about ways to find their portability/migration issues so that their code works with a decltype-based result_of. We may decide to hold here for a few releases, or until vendors start shipping non-broken decltype implementations. Only after folks have had sufficient warning and time to adapt could we think about making decltype the default. Sincerely, -- Eric Niebler BoostPro Computing http://www.boostpro.com