Boost logo

Boost :

Subject: Re: [boost] decltype and incomplete types
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-04-07 16:04:09


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.

> 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.

Overload resolution may require S to be complete, in some circumstance
at least. Of course, if S is not complete, prototypes using S could be
dropped from the overload list, but in any case, I believe the
decltype of a call expression would be complete after overload
resolution. Not sure about that though.

>
> 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.

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.

Daniel Walker


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk