Re: [boost] decltype and incomplete types

Subject: Re: [boost] decltype and incomplete types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-04-08 14:18:36

On 4/7/2010 1:04 PM, Daniel Walker wrote:
> On Wed, Apr 7, 2010 at 12:46 PM, Eric Niebler<eric_at_[hidden]>  wrote:
>> On 4/7/2010 9:21 AM, Daniel Walker wrote:
>>> 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:
>
> Not to be pedantic, but call expressions don't exactly have a single
> "declared type." Their type is determined dynamically by the compiler
> according to the context in which they are evaluated.   The same call
> expression may have different types in different context.
>
>>
>>   // found in some header somewhere
>>   struct S;
>>   S foo();
>>
>> What is the "declared type" of the expression "foo()"? Obviously, it is S.
>
> It might seem so at first, but consider:
>
> struct S;
> S foo(int);
> int foo(S);
>
> The type of the call expression foo(x) depends on which function is
> statically chosen after overload resolution. Overload resolution may
> not succeed unless/until S is complete.

7.1.6.2/4:
"The type denoted by decltype(e) is defined as follows:
— if e is ... or if e names a set of overloaded functions, the program 
is ill-formed;"

Note that your program is ill-formed if you try to take the decltype of 
an overloaded function set. It continues ...

"— otherwise, if e is a function call (5.2.2) or an invocation of an 
overloaded operator (parentheses around e are ignored), decltype(e) is 
the return type of the statically chosen function"

<snip the rest, which is not relevant>

> Unfortunately, I don't have time to participate in the CWG discussion,
> so I'll just comment here. Let us know how things turn out. I'm sure
> the confusion will be resolved.

So far, it looks like the proposed resolution to allow decltype of 
functions returning incomplete types is moving forward.

Now, I'd like to re-raise the issue of commenting out for now the 
decltype-based implementation of result_of both on trunk and release. 
This is time-critical and a blocker for proto, xpressive and spirit on 
msvc-10, gcc in c++0x mode, and any other compiler that implements 
decltype. Let's do it on trunk, see what breaks (nothing, I hope) and 
try to get it in 1.43. We can always revert later.

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