On 4/7/2010 1:04 PM, Daniel Walker wrote:
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.
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