Re: [boost] [result_of, tr1] decltype and incomplete types

Subject: Re: [boost] [result_of, tr1] decltype and incomplete types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-04-12 13:28:44

On 4/12/2010 8:05 AM, Daniel Walker wrote:
> On Sun, Apr 11, 2010 at 5:47 PM, Eric Niebler <eric_at_[hidden]> 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