On Wed, Apr 7, 2010 at 12:46 PM, Eric Niebler <eric@boostpro.com> 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