Re: [boost] decltype and incomplete types

Subject: Re: [boost] decltype and incomplete types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-04-07 12:46:16

On 4/7/2010 9:21 AM, Daniel Walker wrote:
> On Tue, Apr 6, 2010 at 11:50 PM, Eric Niebler<eric_at_[hidden]>  wrote:
>> On 4/6/2010 6:22 PM, Daniel Walker wrote:
>>> So, it seems the draft requires compilers to reject code taking
>>> decltype of an incomplete type.
>>
>> Ouch. The implication is that we can't sub the TR1 implementation of
>> result_of with the C++0x implementation without causing some valid code to
>> break. That's terrible. Let's hope this is just an oversight. I'm following
>> up with CWG.
>>
>> In the mean time, what are the chances of backing out the decltype-based
>> implementation of boost::result_of completely (until we have a better plan)?
>
> After considering this for a while, I believe there is an argument in
> support of the current decltype specification, at least with respect
> to result_of. result_of is supposed to give the type of the result of
> a function call, i.e. the type of a function call expression. A call
> expression cannot have an incomplete type. So, result_of cannot have
> an incomplete type.
<snip>

Strongly disagree. Decltype (decl-type) yields the "declared type" of an 
expression. Consider:

   // found in some header somewhere
   struct S;
   S foo();

What is the "declared type" of the expression "foo()"? Obviously, it is 
S. And if I do:

   typedef decltype(foo()) s_type;

... I expect s_type to be a simple typedef for S. Nothing here requires 
S to be complete.

The issue is currently under discussion on CWG. Nobody there has yet 
disagreed that this is surprising, unfortunate and unintended; and 
someone has already proposed new wording.

> I think a good solution would be for boost::result_of to offer a
> backwards compatible mode. So, in c++0x if the user defines, say,
> BOOST_LEGACY_RESULT_OF then boost::result_of will follow the old TR1
> protocol. How does that sound?

Not good. Proto will need to define that to continue working. That will 
lead to ODR violations when someone includes utility/result_of.hpp 
before proto. I still think the best solution is to roll back the 
decltype changes to boost::result_of until the dust has settled.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com