Eric Niebler wrote:
Specifically, the change is about how decltype of a function call expression is determined. * N3242 says that in 7.1.6.2 p4: if e is a function call or an invocation of an overloaded operator (parentheses around e are ignored), decltype(e) is the return type of the statically chosen function;
* N3290 (FDIS) does not have such a wording. For a function call expression, decltype(e) is determined by the last rule in 7.1.6.2 p4: otherwise, decltype(e) is the type of e.
Right. I spoke with James Widman about this. He says the change was not because of the decltype v1.1 change, but rather about fixing core core issue 1212:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3368.html#1212
Thanks for providing the information! I understand why the rule for xvalues is added, but I don't understand why the rule for function calls is removed. This removal is a breaking change... [snip]
James Widman also agrees with your analysis. I guess the result_of tests are wrong then.
To accommodate both N3290 (FDIS) decltype and pre-N3290 decltype, we need to modify the failed tests to something like this: typedef const int F(); BOOST_STATIC_ASSERT((is_same< remove_const<result_of<F&()>::type>::type , int >::value)); Or, should decltype-based boost::result_of emulate N3290 decltype even on a compiler with pre-N3290 decltype? Also, the implementation needs to be modified. The current implementation of decltype-based boost::result_of does not use decltype for function pointers. So, for "typedef const int F();" * boost::result_of<F&()>::type is int, * boost::result_of<F*()>::type is const int, on a compiler with N3290 decltype.
Could you file a bug?
OK, I will file a bug later. Regards, Michel